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PREFACE 



This report constitutes' the proceedings' of a three-day 
workshop on information. resource management tools, 'held in 
Fort Lauderdale, • Florida on October 20-522, 1980. The 
o workshop was sponsored jointly by the Institute for Computer 
Sciences .and Technology of : the National "Bureau of Standards 
(NBS) and the Association for Computing Machinery (ACM). 
: The workshop continues the close working relationship ' that 
was started in «1972 between the Institute and the ACM. 

■ . The firs t workshop in this series was Data Base 
Directions: The Next Steps , held in October, 1975.~~NBS pub^ 
lished the workshop report as Special Publication 451, and 

,/ it ,was reprinted both by the ACM Special Interest Group on 
the. Management. of Data and the ACM Special Interest .Group on 
Business Data Processing. The -British Computer Society pub- 
lished the report for European distribution, and it was ex- 
cerpted by the IEEE and. Auerbach^ 

The second workshop, Data Base Directions ; The 
Conversion — Problem , ~ was Wld on November 1-3, 1977. it adP 
dressed the questions: "What information can help a manager 
assess the impact a conversion will have on a- database sys- 
tem?" and "What aid will la database system be during a 
conversion?" The report* hafc been published by NBS as Special 
Publication 500-64, and as a joint publication of the ACM " 
Special Interest Groups on the Management of Data and Busi- 
ness Data Processing. Portions of the report were presented 
at the 1978 National Computer Conference. 

The. purpose of this latest workshop was -to generate in-' 
formation that Federal and private industry managers can ap- 
ply to evaluate and select informationV resource management 
tools, especially data dictionary sysftems, and use them ef- 
fectively. Such information is becomihb increasingly impor- 
tant to Federal agencies working to manage the enormous col- 
lections of data characteristic of todayYs operations, j 

The .workshop divided into four working panel's to con- 
sider infbrmation resource management tools from the stand- 
^ point of uses, policies and controls, logical database 
? design, and physical database design. Each panel prepared a 
draft report, which was then put into final form by the 
panel chairman for submission to the proceedings editor. v 
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•Because* the participants in the workshop drew on their 
personal experiences f they sometimes cited specific vendors 
and commercial products. The inclusion or omission of a 
par.ticulaiT company or product does not imply either endorse- 
ment or criticism hy NBS. 

We, gratefully acknowledge the assistance of all those 
"who made the workshop possibly. V . ' , 



\A}an Gpldfine, Editor 
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• " ' f : ' > ' EXECUTIVE" SUMMARY 

J: ... - f 

• g ■ • -» ■,"..■■■*■. r 

• f • •••.'*•■•"'•". • i 

On October 20-22, 1980, this' Institute for Computer Sci-~^ 
ences and ^Technology! / of the National .Bureau of Standards 
(NBS.) and x the Association _ foir Computing Machinery (ACM) held 

e> the third in their series of Data Base Directions workshops. 
The goal of this workshop ytas to generate information that 
mankgetfs can^apply , tpYevaihate, select, arid effectively use 

- informatibo resoatce 'management, tools. - , 

• Among these tools, v a ^central role is/splayed by,* data 
dictionary systems , (DDS) > which have become basic: to all 
Phases of data administration. Managers increasingly turn 
to ^data^ dictionary systems to satisfy requirements for in- * 
formation resources management (IBM),', to /aid ' in database 
design, and to provide the information needed for the effec- 
' tiv'e auditing of data. 

J|herefore f T the workshop was organized into four working 
pjane^jEpI which met to discuss: * % 



* 



* 
* 



Uses of the Information Besource Dictionary System 
for IBtf 



IRM Policies and Controls 



Logical Database Design 
Physical Database Design 



The workshop participants realized that their first 
priority was to develop a working definition of information 
resource management that would allow them to focus on the 
key issues. The definition that evolved was: 

Information Besource Management (IBM) is whatever 
policy, action, or procedure concerning ^informa- 
tion (both ' automated and n.on-automated) which 
^ management establishes to serve the overall' 
current and future needs of the enterprise. .. Such 
policies, etc. ,\ would include considerations of 
availability, timeliness, accuracy, integrity, 
privacy, security, auditability, ownership, use, 
and cost-effectiveness. 
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. Uses of the 'information Resources Dictionary System for . IRM 

This panel investigated the question of how data dic- 
tionary systems could be' used to support managed information 
'environments and help organizations realize the' benefits of 
an enterprise-wide information resource system.. After gen- 
eralizing "data dictionary systems" to ."information resource 
'dictionary systems (IRDS)," the panel examined tbe question 
from three perspective^: * ' •.. 

1. the enterprisers- organizational perspective 

2. the perspective of information systems supporting 
the enterprise ' :: J 

. 3.. - the perspective of the enterprisers database ■ - 

■ ••»*.' * ' * > 

From the organizational perspective, the panel conclud- 
ed that the IRE(S should provide information both for those 
> managers directing the business functions of the enterprise^ 
and for those managing its information resources. The IRDS 
shows functional. jnanagers what information is, available, the 
form In which it is available, where and' how to obtain it, 
and its probable cost. Information resource managers need 
the IRDS for analytical data on how often and how effective- 
ly the resources are being used, as .well as to help them 
analyze and assess the impact of proposed changes to' an in- 
formation resource. " *" ;■' ; 

. ft 

The- panel then examined the potential uses of the IRDS 
during the phases of an information system life* cycle. For 
each phase, a table was >copstructed illustrating how the 
IRP£> is trfeed by various categories of users. For example, 
during the requirements phase, the information "customer" 
defines the generic business applications' and methodologies, 
and the information* resource manager ttien translates these 
to the context of the enterprise's information resources. 
The overall application is reviewed, through the IRDS, by 
the data-auditor. 

r~ 

The third perspective viewedthe IRDS in relation to 
the development of f access, to, and support of enterprise 
databases — both automated and non-automated. The IRDS is 
used globally to view all data independently of environment 
and physical implementation, and to support the functions of . 
co&eeptual database design, -enveloping prototype systems, 
and data modeling. Operationally , the IRDS is used as: ^ 

* a directory of the enterprise's data and information 
* resources, providing the locatiop (and a path* ^ to ob- 
tain) the needed resources » 



\ 
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* S "s&pport for a - given< database -.management system 
. (DBMS) • Here the^IKDS. is. used by the database ad- 
ministrator to ^describe, and monitor databases, gen- 
- erate scheinasV Bnd -iirpiement integrity rules and ac~ 
cess constraints. ,/ : • ''•}}•■ ■ % *, 



IRM Policies and Controls 



This panel* was* charged 'with ^investigating the policies 
an organization requires to establish "standards and controls, 
in an IRM envifoninent. Since the ^members of /the pane^l had 
been drawn both from the IRM t^chnolocj^ sector and from the 
internal atraitin'g prof essiop, it-was decided to divide the- 
panel into separate tecdinolbigy: ^irdT'dUdit'liEig working groups. 
The f inal report of the ^anel^comb'ines^.the f ijidings of *fche 

two grougs. . 4 v " •">•:> " ' - w ~. ' " • 

■■■ ■ .. - t ■ :' ' f ; ■ . ,/ ■ 

The panel developed a'*set of fundamental / IRM V policies 
for' a • hypothetical organization; These policies emphasize 
the need for ajv^Lntegrated set of planning doc^ents.:- 

* a strategic* system architecture plan . " 

^ * a long range information -plan^ ; : ■ . m ^ ^ * 

* guidelines for the. use ofi di^ionariesr " languages > 
databases f and networks V - # v ■ 

* a data standardization" plan ^ 

* % s 

After outlining the strategic system architecture -plan 
(the key document) tke panel identified specific policies 
that are important to the overall success of MRM. The re- 
port discusses or lists ^deliverables^ applicable computer- 
based tools $ concerns about toois, IRM control, policies and 
auditing risk * exposures. These /fcoliaies affect all- phases 
of the infbrmation system life-. cycle, and have a, significant 
impact "on^ other - areas 6i an enterprise.". : J ^ - 

Logical Database Design " . ■ > - 

*rr • * 

This panel addressed the issues of IBM* as they relate 
to the process of logical -database design. To best explore" 
this . broad area, the panel was< divided. irit*o four 'working- 



groups: 



1„ Retirements vftnaiys i s/Asses sment of , User / Needs . 
. • • This. 0 wording group cldsely examined the process by 
V' which a meaningful statement of an enterprise's in-, 
formation requirements is- developed. The g'r oup con- 
cluded that . ex i sting tool s.- and me thodolog i es in. thi s . 



v > ar«a have fa number of desirable features} but that 
■ ;3*o, VBingie ;t«?hi[^ue. : si^s ; but. Data dictionary 
.•• systems were emphasized as:: % v • • 

- " •:*:. a repository; bf the info* rmat ion col lected dur- 
• v ' • i.hg th%' analysis v '.- .j ■ , • ■ "X. 

: ''*Y-;f$.;Co#trol mechanism v '.:;.••■•.•■ 
' a; tipoi to. perform basic analyses 



,* 



i- ^ , •* ^a -manager- of a database to which more sophi dti- 
cated analytical tools* may be applied* 

2. Information Modeling. This group identified the 
basic processes involved in developing an "integrate 

• . ed, formal, implementation- independent specification 
of. application-specific enterprise information. " The 
group surveyed the better known informations-models'' 
and the existing' tools for database design. They 
'.developed the concept of a "database workshop" to 
support the design process. This workshop would 'be 
built around jsrdat'a dictionary, which* would play an 
active' role as a repository of metadata about the 
database being designed* . ' ■ .--V .* 
■ \:' 4-' - / ' ' ■/• '■■>.■■<■■■:;■ 

3, Interface between' * Logical and Physical Design . This 
. group - : dliseussea^^\t^e;^-^]eiabionships between logical 

• and physical design. .- The members reviewed some 
results, of logical deslg^which influence physical 
design raec i s ions,, and examined the* impact 'of ph£s ir 

/cal desMn dec is ions on logical^ database design. ' 




• 4. Role of * Data Dictionaries "in Management of' Data / 
' - This group " summarized the role of. the -DDS as per- 
forming; the functions of "planning, control; direc- 
""' f tlon, and, organization of the information resource. " 
The. members concluded that while" a ~data dictionary 
.is integral to a' database environment, the DDS it-. 
, self should be independent of jth e DBMS . r They iden- 
tified; a list of DDS features helpful' in designing 
databases, both in di stributed 
vironments. V 

Physical Database Design 



and centralized en- 



> This panel investigated the physical issues of database 

design using- a data dictionary system. Once again-, a system 
life cycle framework was; chosen to describe the uses of the 
DPS: '. 

^ - 1, TJser iteguiremehtis Phaser Thfe- dictionary for > a new 
* ?' r~: aatabase is initially createB during this phase us- 
logical design components^ such as entities* at- 
^ t^ibutesr ; ' y. The bol,lected 
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"metadata* or data "about ,da^a is the same as would • ■ . 
k ^/collected in a. non DPS environment. , . . * • 

2. Physical Design Phase r .The panel identified, thi Me- 
tadata needed to describe decisions arid_act ions Sthat 

\:^' le^tto ai specif ic database design. " This metadata 
is also necessary to determine the distribution and 
piacement: of records, within the available storage 
apace, and the specification of .procedures leading 
towards validat ion of the database . 

3. Implementation Phase . This phase can be .viewed as' a 
conversion V. from an old system or design to a new 
one; Certainly the DDS should reflect . information 

r abotit ther nej* design/ and possibly, £bout the older 
re* design as well* However/ the panel wondered why. it 
shouldn't also be possible to , use an active DDS 
directly to assist in. the autpniiatic 'installation of 
. the database. ''■:>/ > : - . : i ' 

-4. Operations . Phase . The DDS is the vehicle for docu- 
menting the answers to these questions: 

■ .' ■ . ,'* x . ' 

* What was the desired performance* from the re- 
quirements phase? . 1 ' : r ■ 

. * What was the predicted performance from the 
■ . design phase? ^ .v - 

* What is the actual performance during the opera- 
tions phase? 

<; * What are the estimated characteristics of data 
* ■- and usage from' the requirements phase? \ •/ . 

* What are the actual characteristics of data and 
usage during the ope phase? 

5. Evolution Phase . Reorganization „and Redesign may 
require major changes to; the def inition^f the data. Y 
Most of, the metadata that the panel identified as 
necessary during the physical design phase would be 
needed here also. 

6. End Game Phase . The panel recognized^ the possibili- 
ty r that the operation of a database might at some, 
time -be. shifted to a distinctly different mechanism. 

. 7 The DDS then would play the role it does during the 
conversion in the implementat ion phase. The archiv- \ 
ing features of a DDS would be especially important" 
here. / J : .£ ■ . ■" 
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DATA BASE DIRECTIONS . r : V 
INFORMATION RESOURCE" MANAGE^NT--STRATEGIES ^TOOLS' 

Al^n H. Goldf ine 
• : Editor - :• 



, This report^, constitutes the results of - a 
th^^ee-^cty-worJcsKo p .on inf o rmation resource man age-- 



ment tools, held in Fort Lauderdale, Florida \ on 
October 20-22 , 1980." The wbrkshopTVas sponsored 
.jointly by tfhe* Institute for Computer Sciences and 
Technology of the National ; Bureau of Standards 
(NBS) and the Association for Computing Machinery 
(ACM): 5 - - 

• ■ •■ • ' * :• . 

Patterned after the two previous Data Base 
Directions workshops f this workshop. Data Base 
Directions ; Information Resource Management — • / 
Strategies & Tools, investigated how managers can. 
evaluate, select, and effectively use information 
resource management tools, especially, data dic- 
tionary systems. !fhe -approximately ^^seventy 
workshop participants were organized into four 
working panels, which met to discuss Uses of the 
Data Dictionary System, IRM Policies and Controls, 
Logical Database /Design, and Physical Database- 
Design. . .V *; $ • 

Key words": data dictionary system; data management 
database; database , design; DBMST information 
resource management. 
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I. INTRODUCTION 



Mayford Ik. Roark' 
GENERAL -CHAIRMAN 



Biographical Sketch 



Mayford L. Roark has headed the information systems 
function at Ford Motor Company for the past 15 
years— first as Assistant Controller, later as Direc- 
tor of Systems, and presently as Executive 
Director—Systems. Mr. Roark joined the Company's 
Ford Division in 1952 as a Senior Financial Analyst, 
and managed several financial departments at Ford from 
19155-1965,. 

Mr. Roark was a Budget Examiner at. the U.S Bureau of, 
the Budget from 1947 to 1952. Previously, he was with* 
the U.S. Weather. Bureaiu and the Colorado Department of 
Revenue. * 



He is a graduate of Jttie' University of Colorado, where 
he received his BA (Magna Cum Laude) in 1940, and a 
Master of Public Administration degree in 1942, 

He is past Vice President of the American Management 
Association, and was General Chairman of the 1979 Na- 
tional Conference of the* Association for Computing 
Machinery. * 



1.1 THE FIRST TWO : DATA BASE DIRECTIONS/ WORKSHOPS 

Five years have gone by since the first Data Base • 
Directions -workshop in the Fall of 1975. That meeting was 
.^concerned about the fundamentals o£ ! dataSase art— the 
language structures, the standards needed to govern future 
growth, and the benefits to be- expected- from the database 
environment. * 

: Data Base Directions II, in late 1977, addressed a more 
advanced problem — that of conversion. Already it had become, 
apparent, standards notwithstanding, that ma£y of us would 
be faced sooner or later with the task of adjusting from one 
database environment to another. The value of, these 



discussions \ was brought home to me two years later when 
there was a!n urgent phone call;.frcmi a.systema.direator: o£ta" 
large-scale government organization who said/ "I've ,;been 
told by : my Xroanagemen t to convert at bnc^^rom batch^to i 
state-of-the-art database environmeht . .The proceedings "of 
Data Base Directions ,11 ar$ the" only literature I ^e^ been 
able to find oaXthis problem. n V- /v,^ v \ 



\ 



.Data Base Directions III has tecogfiiized' a gro^ifigVTtfatu- 
rity and acceptance o£ database systems. In late 198oKmost 
organizations were directing their ma jojf v systems development 
toward on-line, database systems. The software market 
presented ah outpour ing\ not only of database management sys- 
tems, but also of related products for the management of 
these systems and for the information resource as a whole. 
The* evaluation of the resulting w S€rategi^s and Tobls^ pro- 
vided the* theme for this t v hird Data Base Directions workshop 
on October 20-22/ 1980. V ■": 

1.2.1 Using the: Data Dictionary S^fe^em. 



The most obvious of these, to<5fs'*is the data dictionary 
system. Although most organizations have by now accepts 
the idea that information files ought to be organized in- 
dependently of the computer programs they supports it is 
quite another thing to keiep track of the -contents of these 
files as they expand to. encompass virtually every segment of 
information with which an organization is concerned, v Mos N t 
suppliers of database management systems have developed data 
dictionary systems to accompany their, offerings. Seyeral 
software firms. have developed independent data dictionary 
systems'. Most of us are still struggling to learn how best 
to use these ^ools for managing the rapid growth in our in- 
formation resources. V 

1 »2. 2 Standards and Controls • \ y % 

As always with the -pr 61 if erat ion of new . technologies, 
the explosion of information databases has led to a cry ~for 
^standards and contrQ^sv 11 How. can. we k . apply standards and 
controls without stifling the growth* we are trying to 
manage? This was a second thiSme of Data "Base * Directions 

nr.* > . ■■ ■■■ ' • ' ' 
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1.2.3 Database Design. 

Finally, the growth of our databases has confronted us 
with serious problems of architecture. In the database 
field, we must consider two kinds of arehitectijre — the "log-^ 
ical database design 11 and the "physical database design. 
Although these may be related, they are influenced by dif- 
„ ferent ^ n eeds . and cons iderat ions . Data Base p i r ec t ioris -J I 
deal t with . these * problems through two additional study 
groups..; r v j5fe>v " 

j - • * ■. 

1.3 CONCLUSION ^ 

All three Data Base Directions workshops over this five 
year span have attempted to draw on the experience and 
skills of individuals who have achieved distinction either 
as practitioners or "*as ■ students ' of database "art. The 
proceeding^ of these discussions therefore* provide an in-, 
valuable compendium of the accumulated ^experience of people 
who have been closely involved in the/ identification" jand 
solution of problems at the leading e^ge of database tech- 
nology . • : • , ' : • , . 

As a participant in these discussions, I. found the in- 
dividual workshops to be an invaluable stimulus to my own 
thinking and a rich source of ideas. All of who partici- 
pated, iii the meetings will hope that you, the reader, will 
share in the inspiration that we were able to gain through 
the three days of face-to-face meetings with our colleagues. 



2. DATA: THE- RA^' MATERIAL OP A PAPER FACTORY * 

• John A. Gosden • * ... 

V;. *" REYNOTE 'SPEAKER . . 

Biographical Sketch 

John GosdeH^is the V^ce President for Telecommunica- 
tions, for the Equitable Life Assurance Society, where 
he is responsible for ^planning, providing, and recom- 
mending jnariagement. policy for all electronic communi- 
cations, both voicfe and data. He joined Equitable in 
1970 as * a Second Vice President in charge of the 
Technical Support Group. iProm 1975 to 1978 he was in 
charge/of Corporate Computer Services. 

• Mr. Gosden was with MITRE fr<5mT 1966 to 1970. / Prom 
1966 to l9$9 he was head of k the Program Systems Design 

, Subdep a rtment, and from 1$69 to 1970 he was head : of 
the : Information jsy s terns DeparSfigHt~p:f~~ tfre Nat iona l- 
Command and Control ' Systems, Division of the MITRE 
Corporation's. Washington office. Previously, he was 
with Auerbach Corporation and Leo Computers. 

In 1977, Mr. Gosden, was chairman of a Federal Advisory 
Group on White. House Information Systems, which re- 
ported on ways to Use^ information^ systems to improve 
the decision making processes of the President. - ; 
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2.1 AN INTERESTING CHALLENGE 



It is an interesting challenge to compose a keynote 
speech to such a specialized and -expert audience. A dozen 
years ago I managed several projects and was Aver y involved 
in databases. In the /last ten years my experience has been 
with autcmation of a factory. An insurance company's home 
office is basically a paper factory 9 and the raw material is 
data. In the last twenty years insurance companies have au- 
tomated the basic production lines and have pioneered many 
applications. Now we are looking at the future and there is 
much more to do> and one of the crucial technical problems 
is how we handle data: store it* index it, access it, update 
it. My speech today Is ^essentially the content of a paper 
originally prep'a^ed for my top line managers. The material 



' "has not beeo mc^if ied This* "is 

the way- we / described the next twenty years> how. computers 
and. communications will evolve/ and "how we expect business 
to reaebr^ I thinK it an in ten: es ting commentary on 

today; s insurance managers that such a paper with a strong 
technical background is an inrpprtant part of their planning. 

Sect ion 2.2 d iscus s6s current changes * in T technology 



that will be familiar to you. The two systems mentioned/ 
CAPS and EQUI-CLAIMS/ are large, on-line/ centralized data- 
base systems • that support over half our labor and paper- 
intensive^ business activities* They cover over 3/5.00/000 
individual life insurance policyholders and some 20/000/000 
people covered for health insurance. These systems depend 
on" databases. For these and many other applications we run, 
data "dictionaries are a crucial tool. 

*■ Section 2.3' . discusses; a social and business 
phenomenon--ins tan t . service. '\ We use a code phrase: "I 'want 
it now. w Technology makes it possible. Business f i^ms ex- 
ploit it to get a competitive advantage, whether it is^ne'ed- 
ed or not. Then it becomes a "want/" and a commercial im- 
perative. Thus V improved service becomes important competi- 
tively^ This is complicated by an increasing volume of data 
that is made available fry automation. ; . ■ 



Section' 2.4 predicts how managers and management must/ 
and will/ react to the greater service demands: 

* Managers will become more analytical. 

* w One-stop-processing ,, will be the dominant mode of 
processing. > * a 



Service representatives will become key staff roles. 

' * Service representatives will be very demanding of 
their support systems. 

Service representatives and managers will • demand good 
data services/ and these will be increasingly difficult- tQ 
construct as the. systems become wider-ranging and more com- 
' plex. : ■ - V 



None of this is 'wild imagination;.. All thesfe ^rends are 
in place and happening today. The pace is determined by 
pragmatics, successful, implementation, and the- competitive- 
'.situation.. ■ . «•.••/;•'•-- . £ • .'• •• 

The major point I want to establish . and reinforce -with, 
you is that service -considerations will drive database, 
design much more than is now. the case. ,:. We —will' want con- 
venient" access to a wide-' r ange of-data. it - will need-to. be 
linked together and cross-referenced in a number of ways, 
and 'these ways may be continually modified. This indeed is 
a very difficult problem] and we will be waiting, for your 
.solutions. J • 

2; 2 CHANGES OCCURRING IN TECHNOLOGY * . = 

Over the last thirty years there have been dramatic 
changes in computing and communications technology. -The 
computer has evolved as a powerful tool,, and has been in- 
creasing in power more than tenfold each decade. We now 
have a wide array of computers: large, medium, mini, and 
minute — even pocket calculators that are more ' powerful than 
the large computers of 20 years ago. Communication technol- 
ogy has also grown dramatically'.. We nW have large networks 
of ter minals and com puters. . We have changes in telephone 
sy S terns every few years in'ste ad u£ a very-stabl e a nd s t a g ^. 
nan t set of systems. Communications and computers have made 
possible* large systems jsuch as GAPS and EQUi -CLAIMS and have 
provided a basis for regionalizing service while maintaining 
a common. system and centralized databases. 

Where is technology going in ; the future and how will it 
change' our way of. doing; business? We expect dramatic 
changes to continue in the next twenty years. The .major 
changes that -we will see will occur because systems and , ser- 
vices can be larger, more comprehensive, faster (or more 
responsive), and all at lower costs. There are more than 
enough new ideas around, aria as costs . come down new ideas 
become- ' economic and attractive. What follows : are some 
developments that -I expect . to become available. : ■ 

2.2.1 Speech Tiling . ' \- ' ■ ;.; ' ' 

;. Many simple telephone messages will be automated. To- 
day, ' people leave messages to call each other back; this 
causes -frustrations and delays. . Soon we will have systems 
with which we will be able to dictate messages to. each other 
and call up dn our own telephones to 1 isten to tWe messages 
dictated for us; ^The -messages can be . stored, and -wen ,f or-:, 
warded to others. Any new message can be automatically .sent 
to a list of people. If you are away from your telephone 



you can dial in to get your messages. '".-. w : > 

2.2.2 ^Electronic Mail and Storage. \ * '.-A'. 

Messages, memos, letters, and. contracts that need -to be 
in writing will- appear only rarely on paper. They will be 
prepared on- terminals, sent » electronically over networks, 
read from a screen, indexed and filed electronically. 
Managers*-arid staf f- will -be able- to use- terminals - to scan and 
retrieve documents needed to review history, or to record 
answers to questions. Paper and copying Icbs'ts (dollars and 
wasted time) will be cut (drastically, I hope), mailing de- 
lays avoided, and many problems of keeping' files up to date 
and finding things in them should be much simplified. 

2.2.3 Image S tor age . 

~ r . ; •• - 

.. Some . important, documents, photographs, signatures, and 
letters that arrive in non-electronic form will have to be 
stored. Today, these are filed because they- are too expen- 
sive to store in .electronic form. With reduced costs We 
will be able .to afford to -supplement automated electronic 
filing systems and keep such documents as "photographic" im- 
ages in our electronic files, thus eliminating more paper, 
and saving' the problems of transcribing them. 

2.2.4 On-Line Reports, Analysis, Graphics. ^ 



. -The -new systems cannot simply present raw data* to exe-* 
cutives. Just having all the operating data on-line does 
- -•• - n9t. mean a manager can just press some " buttons and see a 
y useful management, report. Actual results that are different 
from predictions or plans need interpretation. "Experts will 
have to analyze and filter results, look for causes, and 
separate the effects of each. They wi£l use powerful on- 
line analytic tools * and create management reports using 
graphics technology to produce diagrams; tables, charts , and 
v • , graphs to" display • results. . Where models have been 
*' ' ^developed, new trends can be, fed into them to project possi- 
ble changes; and allow "management to consider new alterna- 
tives. - ' V .. \ ■- . - ' . 

2.2.5 Retail Databases . .s. . 

.v.'.. Today, there are' some databases maintained and avail-? 
. able for/"* a fee: Stock Exchange prices and volumes; "indexed 
legal rulings * trave'l and vacation data; industry statis- 
tics; and several government statistical publications v More 
. of .these- services will be available and used by managers . 
v Private exchanges may well develop, and we may also expect 
in-house databases to be organized so that they are' useful 
... to. other parts of She organization. For example; both the 
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personnel office and the /controller need to look at employee 
data.. * • .-i/ 



lin es needed are e x pensive and take time to inst al l. By- 
2000, cable TV systems will allow home terminaIs~to be con- 
nected to company systems without having to install special 
lines, and without being restrictefd by the limited capacity 
of telephone lines. .* 



. Sophisticated cable TV, including, systems such as 
"viewdata, will " become available . Viewdata is a new type 
...of service that enables suppliers to make statements^ avail- 
able about their service* and products. . . Viewers can: tune in f 
scan for products they are interested in, see a telephone 
number# call up, and conduct business . Many, simple func- 
tions Will be carried out by a simple keyboard, similar to 
one on a touch-tone phone , and the TV screen will be used 
for replies. In short, a large variety, of devices and ser- 
vices will be developed around the .home market. 

2v2. 8 One-Stop Processing. 

One-stop processing is a term used to describe a system 
: ! in which a single person, can provide a complete range of V 
^services. Thus, a easterner can be .dealt with -by one person 
• without having' to go^ to various, desks or counters 'to;be ser- - ♦ 
viced. A good example* * is * ?an * airline - reservation; system 
where one clerk can make all the reservations r check credit; t *\ 
issue the ticket , \ and chWk-^bagga^^ 

good on-line databases,- relatively cheap termihals f V cheap 
processing, voluminous storage/ ah(3 # mb*st of all, the abili- \V 
ty to design and install such systems even though thfey re- 
guire dramatic changes in organizations and in employee at- ; 
titudes. ' : V * - v. .' 4 ,'; . - • '.' -"^r^ '. 



2.2.7 Cabl-e TV Extensions. 



2.3 GENERAL FO&CES -STIMULATING CHANGE 



-v- 



Working alongside: improvements in technology are con- 
sumexism # changes in customers' - expectations/ and some 1 
current frustrations that are stimulating changes in society 
" and business'. : 

m ■ ; ■: - . - L r • : : " '■ : ■ • " ■ , > ; ' ' 

• First, there is a pervasive theme emerging today that 
applies to customers/ employees/ managers— indeed a per- 
vasive theme i^n our society. I believe it will also be a 
characteristic of the early twenty-first century. It is ex- 
pressed in the phrase X want it now! A generation of people 
are growing up <\. in • an environment where they write few 
letters but make extensive, us e : of the telephone . - Thisy 
expect to be able to get a response or action right 
.away—buy something with a credit card/ make; a reservation/: 
arrange an appointment/ get a prescription frdta. a. doctor* 

Second / competitive forces wilL^icontinue to be a strong 
driving . force/ and service ■Qrientation may become , more im- 
portant than price (just as/^witti convenience- -foods) . . Ohce^ 
service. :bec all vendors must adopt such 

an attitudfe or face a declining business. ■;. ... . 

Third/ there is the problem of coping with an increas- 
ing volume of data. Today /ygrbvernmerit and business organic 
zations are drowning in data. At the s ame tifse, the comput-. 
ing arid; communications tecnnoiogies are i n"<srgay hrg " r a pidly ~ 
in scope and power . Information technology/ the techniques 
by which: the- tools are used for the interpretation/ presen- 
tation* and controlled use of data/ ace in the early stages 
of 'development. The current 'substantial investment in "Of- 
fice of the FutuVe" projects by< American business*/ however / 



Overall/ in the next twenty, year a expect that tech- * 
nology/ business, and social J: pressures vvill -'..accelerate- ' 
development of systems that respond faster to the -needs of 
business manag^r^/ staff f ; and customers; . ;} 
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2.4 THE NEW MANAGER'S WORLD OF -.2000 

There is ho single picture :of the £uture--any specif ic 
statement is only a pr edic t ion-- bu t we can predict- a con- 
tinuance of a general trend that already exists. 'There will 
not be one general pattern; Different industries* different 
organizations, 61 f f«entVmanagers wilJL have different needs 
— ^and-dof f erent^-style s, j us t as the y-do to days— That— rs-why-ye 
can give a general pictbre with confidence but specific ex- 
amples are less reliable.; 
" i .. ■ - - .' 

Much of a manager's time] is involved in dealing with 
messages (telephone calls arid memos to be answered) > st^udy^ 
ing data /(operating results, status of projects) ,. making de- 
cisions^ (looking at cJ.ternatives and weighing" possible out- 
comes) , and conducting ox attending meetings. 

A manager will use . on-line systems extensively— some 
directly? v f or ^messages, some for looking at reports, and some 
for- following up. His or. her staff ^will use on-line systems 
to ievleiw results, to .consider alternatives, and to develop 
plans, derating .staff will use on-line systems to perform 
** the basic functions of a business. * r. - 

Good managers will emerge who will operate less by "the 
seat of their ;pants" or iritui tipn, and will rely more oh 
evidence. They will set up systems - that produce operating 
- data4th£t show what is happening, use models to consider al- 
trerncrt [ups/^'hb 'm f ^sft^n^lyH ca oriented t han today. 
It will be possible to make choices mucn. less e f ~ a ojam bler- 
tp expect a faster awareness of,' anci reaction . toy changes. 
Managers, too, will becpme irapatdent. - Their, too, will "want 
it now.* ' ; y ; r . ""■ '; *-J; t ■ ■ 

new /management philosophy and an increasing tempo of 
business will reguire managers to make decisions more rapid- 
. ly> [At the: same* time, with more information readily avail- 
able, it will be^ posisiible to increase the span of control of 
an " r indiyidual manager.;. There should be ; fewer peopl e to deal 
with- exceptions or to ^supplement the aiutomated' sys terns and. 
cpveir the connect ing parts Most of the processing can be 
•'. automated. iThe major "' outstanding functions will be 
analysis, decisions, and customer service; :as well as plan- 
ning. Thus, there will be^f ewer pure Administrators and r 
^bean counters, " and more managers witfc the. entrepreneur ial 
outlook to taJcd advantage of emerging opportunities. ..These' 
new managers .will have a broader scope of ... .act^pn, ; will be 
; morer •^■r.lsfc*. oriented, ^ancl will be held more .directly ac- 
countable for results. ' ' : - •' / ; 



; - 



cKang<e"; tovsuppprt. . on£-stop> j'p^ 
l&es&^ .divided work up so 

^i^t s^arat^ 

ia • tr^s^^ work 
stations^ ■ irv "rtyr^ cti^f an i z <i t i bn # lor ' ei^li?): '^en^e^want. I tp 
deal Twith * a caller !ohri^ at' a) counter ^ ox von^the 

phone >^%e -must arrange tilings so ; ^a^ ^ne . person ^ on ^our: 
staff 'can deal with all >the questions and -actions; the caller 

7 wants-.— We^am^ 

pass callers f jbom one unit to :another. 



• * Employee attitudes need tb change because there is an 
> } ehtirely ^ dijperent * tempo and inter-personal style required .* 
•'■.-Vta- respond ..dB&ectiy to-callexs rather than processing pieces • 
1 of paper* : ^ by the caller ' 

"and work cannot be rearranged into neat: v : piles of similar 
s kind* There - i s no time, to " seria for f ii^js^-^fi^s must be ■ ' 
; ready at hand T^ ,<a 
supervisor-*- too many exceptions; will stop the system f rom 
-v working. .;" ■ v,-;\- '■' '//>■"■■ ' /"/■ ./ :> ;-." ] ~- : ^;+'^>\ -, ' • ■ 

~'\ ,S The tempo pf both society a'nd business will be r affect- . ^y, 
* edV. It- will be' a "dynamic society 1 * willing/ 'able/ and want- ^ ? 
/ing to do^ it now. • 
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Dedicated employeies wanting* to provide ^pod service, can 
be expected to demand that the system and b'ifeanizatiqn sup- \ 
' • ;' port them in their ^obs.. They - will be 1 critical andv iri-^ 
tolerant of inefficient or unresponsive systems/ and of '.; 
inefficient managers who do^ribt fix things or 1 develop >ways 
to respond to new , fesittf^t ions . 3 Again/' a very, dynamic *en- ; 
- vironmetit is going to iemesge . As, emplqyeTes^r are more {r.Van- 
Jjrvdirect service/ management must be more responsive..; 
and le^slTlmtScr^ responsive employees/ . ltfanagersH 

will " Be • called-upoiv^^ going on/ and truly; • 

\cjet employees invQlved;;;in^ ser- 
vice • interface/ tl^e employees will SeJ a lnajor^art^of-^diat^ 
the public sees as; the business.' "Not only will there be & 
need ; for 'imore delegation within ; management to mini and 
mirH-mini -businesses/ but ' many employees will ;t need to ;&V 
consNidered^ as -managers of, their ownr : r t ime >• ; and . company 
resources/ as /they- operate direatly with the public. --^X 
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Where will more responsive employees cotfe from? They 
^,are., .already .The younger generations in 
bur society seem to be more attuned to , "people-needs, " anch 
thus should be sympathetic to a service attitude* \ 

i ■ 1^ expect the combination of 'the 

- available technology, the already established advantages of 
> one-stop processing , management frustrations with delays in 

getting -data/ and a continuing demand" for service to foster ' 

an "I want it now* climate. ' 
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*.Jk* INTRODUCTION 



3.X.1 The Objective > 



; • - ^e objective of this panel was to identify the uses of 
a " data ; dictionary system in supporting ptganizatioris which ^ 

. fea^ the ne&d for and are attempting to implement ' 

an • information resource vmaitagement (IRM) • environment. v 

. Although a data dictionary system>; ; in its most rudimentary 
sense or - its norae^iy understood^ sense r qan support some as- 
pect s of the IRM envi r onlnen t > th<^ requirements . for IRM go 
beyond the functions of ak>s t i f viipt all currently-available 
dictionary systems. • For this -reason it is the consensus of v 
this panel that the, .expression "da dictionary system" ,is, 

Oho longer app^ tool of IRM. 

:'!^e^/&^ressi6h chosen; by the ' panel is the "information,/ 
r££o£i^^ expression was 

> chosen befc^use it i s inherently m^ of the pur- 

pose of -*hi^ t^ .with the trend 

of dictionary systems inrt£ie ma^et ^a^^ : ; . 

?:l -\ Bef ofce. pr oceedihgV • * it is necessary, to explain the / 
panel' s intended meaningr of IRJI arid -IRDS i The - principal- 
points in these, definitions conberA :; the: -broad coVeifage /'■ of 
information and irif bnnatiori- s; r eleyance ±o^ arid ava i labi 1 i ty 
for management needs across the ^enter^r ise V S . 
J ■ ;'' .; " v~: : '- ; ;/i^ ■ \ • .• ', 

* information - Resoiirce Management j l ( IRM) ^ is whatever 
policy r act ioBr ~ or procedure: concerning information 
'/ V (both automated arid non-automa t ed^ s lippor ted ) which 
management establishes tb/ served overall 
" current and fu^^ Such 
policies, -e^ 

availability; timeliness, 'acc^t0^ : r^ integrity , 

privacy, security, audi taM 

cost ef fectiveness. '■ ^i : .J^}-<" ■■ 



An Information Resource Dictionary System ( IRDS ) is 
an . inf ormation -system with automated support which 
' documents ^the information envi ronmenl^of - 'an 4 Alter ~ 
'prise* /supports,, the oper at ionaL aspects of V t ha;t- iri- 
foritfat ion environment, illustrates the .' ' iriiterreia- 
^ tionships of inf ormation >envir onment components , and 
"documents the locations of al 1 \; component s b£ *tfc^ i ri- 
f ormation environment. /"The ^ Information " Resource 
Dictionary i (ljRP) is the 'actual database mariipulated 
6 by the IRpSX software. v v ; ■ 



-18-^ 



ERLC 



23 



IBM; is currently one of the most significant topics bfe- 
ing. discussed concerning information systems , and is being 
discussed; along a variety of lines of thought. These in- 
ClUde business systems planning ; information systems 
analysis, des i gn f and development; da tabase , design an d i m- 
plementation;'" the disciplines .'of .office management,- paper- 
work management, and information sciences management; and 
.~*fche various problems and costs associated with implementing 
IRM to include each of these areas. 

>The panel would like to point out that ISM and an IRDS 
-are; not panaceas. They, by themselves, will not eliminate 
. all of the problems .encountered in the previously mentioned- 
areas. 1 They can support the resplut ion or elimination of 
these problems, but only if the goal of the enterprise is to 
manage the .resources which provide it with information. In 
this -case, all components • of the enterprise's information 
environment must be identified and documented to the level 
which makes the components "-shareable" across the enter- * 
. prise. To realize this goal, IRM; is a necessary function 
and the IRDS is a necessary tool of IRM. .How the IRDS can 
be used to support this goal will be discussed in later sec- 
tions of this panel's report. - • . 

3.1.2. A Historical Perspective. . : ) 

Terminology changes since Data Base Directions (DBD) I 
(1975) and II (1977) are i revealing. The emphasis in these, 
earlier workshops ' was "data".?, today .'it- is "information 
. resource . " Ther emphasis * on "data * management " di scus sed in 
» the keynote speech at DBD II .has evolved to ^information 
*' resource management?' at DBD III. These changes are, of 
course, more than word .change sv : T^ reflect an increasing- 
ly prevalent view that the narrow concern for how computers" 
; manipulate data has' butMved it's usefulness. In is place is 
t a" global ;^iew which is far beyond manipulating data within 
. an^ automated database,'; the view is concerned with \providing 
all, information in the .form and at the time required by the 
enterprise'. r In fact, since it is frequently postulated that 
an. enterprise's' greatest- asset may' be its information 
resource, management <Jf • this 'resource is as necessary as 
management of. their enterprise's personnel arid -financial 
>; resources. T ' >v.-« ■:- " • •'• •" • 

v> ^ ^ v _j v " .", ■ ... \ : . ^ 

. Management "Of *the information resource is a developing 

* aft. Its primary objective is to '. meet , with increasingly 
effective results, the ^need's of the enterprise for informa- - 
tiori. This. . 

dating -of needs, and * development of > informatiJon sys terns 
which meet those needs with either internally generated or • 

• externally -available data. This further requires a- frame- 
work.; /for ; ; the . enterprise and thus necessitates the 



:: >. establishment of pl^ns ahd> policies to assure consistency of 
inf ormat ibxt sys t^s wi th enterprise objectives, plans r 

privacy) r and ■ 

security.* • : r " , . ' 

* - In^lexneritation^of . the IRM concept necessitates the :,y 
cr eat ^qn^ of inf ormat ion systems which might ibe ^called an 
" ^iwf oiniia system .5 Th 1 s -system* in 

order to be effect ive/ must pe^eate the ;eritWpr Ise if it is , 
ta assure' the. integrity of .to informations en- r - 

vironment • Such -an inf ormat ion sys temV to be more thari a 
short-lived exper iment>; must be adequately staffed and fund- „ 
edV and must be " sup^r table wit^ cost/benefit; ana- 

lyses. Both, short-term and long-range costs and 
r benefit s--6f- all ; kinds— must be continually projected and 
moni tored . Over 'timer the \ enterpr i se^s object i ves , priori- ^ 
tiesy Resources r and information requirements $ i t s available 
: technology^ to use inf donation, 

and r the cost/benefit trade-off s associated with information 
use- will change * change is the need f or ^ an 

opt imal jsvix of inf ormat ion sys tfem resources* and the heed 
for management at ~all levels to as sure^ that the^; right : inf or- 
mat ion ' is available at the right time to aid- in problem 
solving and decision-making for the. r entbx^r i se ^ s / 

3»1»3 The Approach., -r/^/i: ' • * ; " 

The problem facing thls^ pahel^Vais to: illus trate how the v r 
IRDS could be used to support managed Irif ormat ion environ- 
ments to realize the concepts and benefits; desc,r ibed r above • . / 
The approach, ^takeii was to : di scuss tfie inf brma%n "environ- • 
ment from? three different perspectives ; 

1., the ente^ris^^ ' . - 

> 2. th^ i?erspectl systems supporting . 

the enterpr ise * ■ •-. " v' : - i 

'•: 3. the perspective of the enterprise s database, .which 
is the source ' Of all data; used b£ its , inf ormat ion 
systems to produce desired. eritei^r ise Information « r 

The organizational perspective section identifies three 
classes of useifs: — / • .■' ;v,- v,; - * 

!• functional manager s. - * 

2. ' information Resource managers ^ „ - 



?<* 3. information consultants 

Four>IRDS metadata classes are required 
- users: 



1. data and information class 

2. source class v 

3. . use and user class - 
, 4 . proce^%;and* ha^dling class 

A discussion of the use[s~ of the entity- types within these 

classes is also presented *\ ' * • 

•■ ■- , k ' .*..... * ■ ■ ...... ■ •' . i . 

The information system approach was to identify the 
. users, uses, and t®es. of use of an IRDS for -each phase of 
r the system^ life cycled &ife phases discussed in this section 
"are: .- "■ , '• % V ■ ■ -V 

. ' ' V: • .: '.' . . . v,., v ;..., .... ■ ^■■-^v- 

1. - the. requirements definition phase f 

2. the development phase (including analysis, 'design, 
' ' arid programming- ai^ s ; t y 

3. the installation^ 

;■ "phase' . . " r ... '■ . ■• , * * .'■ 

4. the operational phiasre v> : ^ * ...... 

5. the maintenance and modification phase 

; : Tables describing ' the > inter f ^latiorxphdp " :: of us^&^.^'Ai 
<; types . ^ and phases, of the: system life cydle are 7 

^presented a^ ^aix ; attachment to this chapter , in Tables 3-1 

■■■through;.:^ . • • 

,:;^^i-U^?The- database perspective approacfe^^ in ^ the de- 

1 f initioiL- of; a ^logical .IRDS consisting of ;ari enterprise- 
oriented dictionary function, a directory function/ and a 
systiem^ specific ^ictionaryVfunction^ of v 

•^/each , of/ these functions is describ£d r in terms* of an . 
enterprisers" databasfe^-whether manuai\or automated br both* 
, Eaclv perspective will" be - discussed in ; detail Iri^:; th§^ v 
remainder of this chapter. v : ^ vV 



to support"^ Hbbese 



I 



.3.2 THE ORGANIZATIONAL PERSPECTIVE 

.. . . • " ' '* '-">.'■' ■ ■■. • ' . : ' v . : . v.- 
3;2.1 Introduction. * v • 



Jiuch qf what has been written* and spoken about IPM em<-. 
phasizesi . ; - ■' • - * ■■- " v '"' ' : 

• * IBM; related technology , both hardware and software 

* the implications of IRM on information systems V and . / 
.-.> - automated database design . . u 

What is too often left uns^aid or lost from -sight is that 
- IRM^s reason" for being* is to serve the information and 
decision-making needs of the enterprise. In th£ " words of 
the keynote speaker of Data Base : Directions X in 1975: "Thfe 
essence of management • ♦ . is , ratkjcfriai ■>. ^decisipn-rmaking. 
based on the best available data . T$isr the Tbr bad questions * 
of data management lie at the very center of the 'management 
process." Extending this more specifically to the topic of 
this workshop* the II$)S, . IRM and all related"*-- policies and 
procedures must evolve to serve the "total .information and 
decision-making needs of the enterprise. ; 

3.2.2 The Organizations the IRDS and IRM. 

; IRM is; an fenlierpr i se-wide management.. progr am which - is 
global in • its .objectives and scope. !Like all management" 
pr og t ams that extend a:cr os s. all organi zat ional component s of 
an enterpriser an- IJM program must strive for informant ion *; 
consistency, ^completeness/ and compatibility. That is,, the 
information resources of Division A must be defined* 
described/ and noted in the IKI*' ^the^to^^l database of ' the 
IRDS) in the same - way as are the inf drtf at ion . resources of 
^Department X. " : :<i : - :7 '^.. m ^ \ • '•' ' 

{'J : The goal of, consistency ha£ several implications for an 
j IRDS and .; the; inform of -which it is a part. 

: Foremost among ' these is the need for the IRDS to support a 
x -\ f top? ^6i?nf >;ajg^roaq&;; This tpp-down approach should^ ref lect / 
; S : the eriterpr iSef.s brganizat ional structure and , pe rhaps mbte ; ^ 
} "4; iu^rt^ enterprise models or 

a long-range enterprise strategy/ and fts association with the- 
■■■T. information systems which support it, as well as the com- 
p^ system.; A significant, feature 

V. W^''-&e:- : %c^ddwn approach is that' it has no inherent limita- 
ry ;tion of depth, and ? wiil\ thus s allqw the IRDS to . support v or-r N 
gah^zational And information components at ail levels of : th^ 
; • enterprise hierarchy, as wel^as a global enterprise view. .'V 

y^XS : * - ■' fi. ••' "'W V"^' ■*>;;. //v: ' : ■ 
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;The deeds and realities of large ' enterprises •-, may ",xe^ 
quire- them to implement multiple IRDSs to support the opera- 
tional aspects of ERM. All that IRM demands with respect to 
such multiple implementat ions is ports is tency of the IRD. con- 
tent s acrosg-/the~^e4te*pr-i-se> — This-^cons^tency may be' best 
accomplished by treating all IRDS as part of a global, logi- 
cal IRD j the database section of this chapter proposes such 
a model for the IRDS. 



3.2.3 Organizational Users of fan IRDS. 

What is now happening in the IRM environment is an 
elevation of the IRDS concept to. the - enterprise management 
-level. In. thi s arena the IRDS" is used to manipulate not 
only, data about data, but also- data about the information 
environment including specific names, * places, functions, 
etc. , by .which the ^<&t%^*i&*&H&£omgiti<in holdings are 
linked to the structure, functions, clientele, etc. , of: the 
enterprise itself. . Furthermore, if the IRD- is. to be%ruly 
enterprise-wide in is. scope, it must contain references- to 
both internally generated; ^information and information ac- 
quired, from externals sources. 

• • v The IRDS should, provide information about those . enter- 
prise information resources required to support management 
^.eds. at all .organizational levels. / These needs-, exist both 
fbr those mahagexs "directing the business /of the enterprise » 
and f drv those managing its information resources.; • ;ih addi- 
tion;, the IRDS« must support those people within the enter- 
prise /who^bridge the gap between the end-users of the . infor- 
mation and the developers and providers Of the , information 
base. - . •• ' v : -V 

••• j t The panel identified these .user classes a*, functional 
managers , infjormation^Aresource managers , -%nd information 
consultants. A description ,^f each class and its „ooteftt ial 
uses of the IRDS -is provided below. : - : r'' J ' 'yj, : ;■. 

- * .. Functional Managers. The functional managers are 

^^mbs^ charged -with executing the business plan of the en- 
terprise;, to accomplish : thi s they need an inventory 
of information available to thenrto hssist their : 
deci-Sion^making. JThese managers, and.thiir staffs, 
: ^l 1 * " se j th- e IRDS to provide a catalog of available 
■ f. * - _-^nfprmatioh^. r .,..;The. IR^ can give a perception of what, 
is available; the - form.: inwhich it,. is available # 
v where and how to obtain it, ambits probable cost* - 
• The IRDS should help these users seal* their infor- 
mation xegtiirements to only -what is involved in 
satisfying . thpse -requiisements and can thus contri- 
bute directly to . controlling information expend i- 
.. •■ ..■ ^tures..^ - ■ ■ . • . • . 



- #1: p 
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/ ;this enterpriser 

tie^ ^ and ob- 

'r j ect i\res r - • Cbntr blleis arid aud i tor s f on the ; other 

to verify gpai^^QOinplishmeht 



aitaong the most: a of : users< 

-~ . Information Re s ou rce Manager s *. These are people who 
are concerned with the cost-effectiveness of those ■ / 
components of th^ information environment used; to. 
V . geiiet atei^f • ; receive, transmit f process/ : and stored in- ' 
-y.-- ^br^ those respori- 

-.isible dr. dat^ 1 collection activities / data adminis- 
.tratibn functions-/ libraries/ telec6mmunications f : 
//office,; ' systemis>- v ani ^^plications systems design , • 
; develo^ent/ " and operation. 

These managers will look to the XRDS for analytical 
^ data on /how of ten arid how effectively the- infdrma-; \ 
ibn : rfesbtitces are b^ing/ used . ,.' The .XRDS should* also 

provide, them' with the i'nform^iQn' Reeded ^to^anal^e v.." 

and assess the impact of proposed chiriges to /art y ift-. 

formation Resource. . ■■ Inf ormaiabn r&souf ce managers/"; ' 
. will also v f use the IRDS to accbmpli sh specials ^ric^ j"-; 
■/> tiopal management,: ^requirements • Such as those : con- \ \ \ 

cerning : secur ity : aiid/or ^iyacy .issues. • '•. ; \ ; // ; \ : • 

* Inf ormatidn -■■^ C6hsdl^nts% ---.'' Information consult ants 
are those intermediateies" wh6j^ '* iifce reference,; li- V 
brarians/ can communicated with* information consumers 



-£/in;^!pfe; ' consumer' s language (s) / * can help the consu- 
mers articulate their -needs --and : ^ frame their in- 
Vi quiries* and* can locate the ifif ormation required to \ 
; sa t i sf y the consumer 's requests 

.Information consul tarifcs/^iil find the IBD an^ in- 
dispensable tool f since it unites data about all? eri- 
• terprise information resources. • They ^wiZl use/^the ; 
IRDS ' to; ' learn sabout both ; tfte exif^riice of desired 
information and its location. In this jcespe.pt/ the 
; IRD contents xdentx^;tl\e;i^a^ y 
of an .enterprise much as the contents of a card ' ca- 
talog Identify the bodksy periodicals/ etc* of a li- ^ 
braryv ■ " •■ ; :• " -.. " 

Requests for inf ormation may be* very general or very " 
specific. For ^example/ .a" state legislator may inr- a : 
quire of the commissi'bher of education/ "can you - > 
give me ^a ' breakdown f pr ^th6 : e;lenr(^tar^ • school s in jayr^ \. : 
district of gra.de>^ >v 



li strict , of entailment figur es; by^sex within g 
f or : >. eaclj vV ^fio61^ tfsed^6y ah in-. 

!brm^i^ the^e* is; ap. 

.. *? T f. ;»•. -'V- ■■ 5 r ^*^ f '':»' * 
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mat ion, or if the data; exi sts in * av f qxm wtiictt ban be 
processed to produce' the desired /information 
I RDS v woul d : . hot fce : used to provide x £h^ 
,, breakdovn ,, itself ^ ■ : •■'■T-. Hi > ; 



3 . 2« 4 Scope of &e information Resource Entity-Trees. ; ■* - 

V 'Th^ contents of the IRD is essentially ^ a weil-def ined 
collection of ^ occur r ences^of entity^ types ;( informant ion en- 
vironmeht components)., the ir ^as soc i a t ed : . attributes:*; .'•ahdv >ja 
representation of relationshi^Svamohg the ent'ity-tyj^es • To 
satisfy the, IRM needs of ^ the Enterpriser the, IBD must' * con- V 
tain at? least the following four /classes . of entity- types : 

; ,1; "The " r data < afid-v information^ qlass< includes - those ^ 
: entity-types that describe data abou^ data Vin both 
its "raw 1 * form and its pr oces sed : form. Included 
• ' among these : ,en^ 

ports, forms,; records/ and Items > .\ 

i 2^. The source class* of entity-types [describes^ the ori- 
v : ^ ' <ji&s vof d'at a and, information;. -These may be cus£o- 
; > mers or iclientsV publishers, \gpvernment, business 

processes ( e . g - , * ma nu fa c t u r i n<j or -saleff activity) , . 
> . " or .even employees* "\ • - ■* ■ r" 

-3. * .The, use and user class of ^entity-types^ ; ate ^ ^ssen-.. 
tially . of two types--enterprise fUnc 
ponents . " Enterpr ise~ functions g • f mahuf acturing , 
- s al es^,^Bccorai t i nig) * reflect thie f ijiictions sup^6r r tihg 
the plan or program of the w eritetpr ise^; Bht^erprise - 
exponents describe \the discrete" orgaMzational 
; ; ^ -\ i '[ 

: 4. The process or hand! ihg; cl£ss^ of ^entity-types coyer 
the breadth and depth of. inf ormatioh : handring; in ^the 
enterprise. They are riot iim 

elated entity-types such as automated^ apjg!4^^ 
programs* modules, ^etc. , but also inplude the infor- 
mation >syst«ns (whet^^ sup^rt^^3b^ co^r- i 
puters). of the erj£erpri>se/ and. toe ^ 
'. . . Vceduites" /us^d by^dter^ise p^tfsonpel lib provide the 
J : v V! ; desired . infprm^tioi^T Thes®;^ 

y. , - •* elude V tjhose' k tffeed * within librar ies record reposi- 
; 0 i tor ies/~ and r document centers.. " I 

Within each cl'aSs^^^ 
H ; • :'a^jbr ; ibut'e^.^^ fully ;'"desdribje 7 ; theieht ity-type ; 

::f aW' ta use ithe entrty^t^^ in an 

: ; v n bperation^I^ ^feenseK.pThe represeiita^iiOT ^ 
^ Ithese entit^-t;ypes serVes^tb w link ff 7 data,, ^n^ 

' ■■ ' -25- 
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> entl^-tyjpes with thei r source , i u s e/' arid " . handling ' ent ity- 
,^YP^-;; ; : ^rtfcermore, there should be- relationships ' between 
Sources and^ * uses#' < sources and,? ^processes, and uses* and 
r processes^i> ■•- ' ' ■ * • 



^vr^^ 'leads to the 

re^izatlori^ £he ^q^ten*s''V:^/ # ihr^;iW^ Is a<?^ua^-Iy a* = 
aiariagc^ 




THE INFOI^TlbN SYSTEMS, PERSPECTIVE 

-'.-""> ..-'^ ' '.■ i • ' ■ \ * = - ■ -. . 

3^3r,lIntrodticgaon^ - # ^ - ^ " . " ; 

^ uses of the iRDS dur- 

ing the d^^elopme.nt' of . an information sysjtem.' „ An -inf ormar 
t^%^stem ' development . begins wi th . an enterprise: problem 
s^ated'as a requirement^ This requiremieht is then r translat- 
ed intp/prrc satisfy the requirement.. During/ 
ttiis eVbliitibp* . theV J^DS i s ^ us^d as a support tool . To xe^ 
la*e. the users of /the^l^ ;p£ the/ ; IRDS,\ 
the eyoiutfbn is-disQussed .herein in the framework of an 'ih-^ 
fbnngftiori systems . life cycle \}iSu^^ : ^l!^^i$^ can h'be ^§ex^f; 
*re^sly useful during the SIC ^ as :a"^pi;rin doct^eriting^" 
maintaining 9 : and. ■ con t r ol 1 ing ; aii. inf ormataoh system's* 
vahaly^is/- * design r ^^nd^ev^opne^Jt/ and r in facilitating its 
operation 



":<,\t ■ ' ....... •- •• • - • - ■ • 



^.\.?y».u.sing' thej' phases^of : an ^information sy/stem" life ■ cy- 
"cleV; vit .": JLs e^sjt^^t6^sj^ci*fy the requirements for the IRDS 
'^^*<is»^fe--3Bii«»^- F^gjli^l:- **^^s^ec^j^ '^&& t Intertdces necessary to tie 
all', .the 'jERD|^ -views-* £ogeth"er -irttb a coherent "ind Thinima3.1y 
nedundarit i;nformati9n systefm. The approach., therefore:, pr'o- 
yideS ' *a"A ifamework for determining, and understanding the re- 
^la$i^^&ipr.of the; IRDS to /■■<snt,ferpr' i'se's information systems- 
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3^3^j Definition of the System Life Cycle. 

■ ••i^^i^ince there is no standard information; system liie cy- 
ca%"' : ^ ; w«- fcAlbwin% : d presented £o define* for 

this jti^ziFySg 'i5L^ : pha^^ -.'andf tfeei£ -us^^^gtir^ 3-1 pro- 1 
vides ar^ictckial >r^te^ V< 

^ Re<iu ^ r enfert ts > D^ s a response to a 

customer^ r.requ v e^J^T|7f or an; enhancemenT:- ^ to an exi sting . produc- 
tion i : i*f orma t ion. Sys t em or- a request * for ;t he deve lopment of 
. an entirely ^> new inf orma t ipri . system. The pqtpul: of this 

r • .. " --26-v : • :' : v _ • - ■ . ' ; ' 















.Level 
-Efftrt 




Analysis' 


Design • 




" ■>'• : 1 ' * r -- . - ;>* 


* Requirements 
[ * Itese ": 


* Developnent 

*• ••• ■ : -. «r ♦ a-» : 

I : • • a' . 
1 • 


"•' '••:->' i 


ifategraticn/ > 1 Phased 
Ccn*^^ "s ;* .„ \ 

!■- Phase - 1 ' ' •. ; * : : '. 



I 

I 
I 



M^inbeoapoe • 



MDdifloation- 



* Figure 3-1 ... Xrif orfoatidn c System Life; qycle ;£ 

phase, would be a pxelindriary proposal whose w key4' cpihponents 

* - a: "rough-cut" view of how th^ 

i * hardware/software;^ requ'ire- 
;r^-" merits** \ ? >' v**.t • ' '.**v v ' V : V * 

" ■ * ■ data .'resofirc^ 

* ' staf f ' resources needed '■■ /^'">^.v.v -v . ' ; v " ^ \>.'. ^' ■ s 
; * intact on other sys v ^ 

^ con^uter resource;^ 

jing ;time) J : '--. V -A .• * : - ; ;: -<'^ 

,* ^fenef itS' (positive and negative; tangible and intati- 

I".---" ^ .^';gible): i-l ...W- ■ ? - ,-" .v ' A.*' ^ ^ 

* sugary : justif ication to continue, or discontinue v.^ 
^\,.-.\^ : -p.y.^Mi^ the deyelopmeint phase ' ; ^ ■ * ■ 

■ 2. Development Phasev c ^ , 0 ^ ^■•■/^■/.••■i^J 

A» Analysis. The analysis stage is: the formal effort An 
■ response to a custcaner: request -f or/an^i^batipin sys-. _ 
;^ tern enhancement development effprtV^^ 




•ft...:-. 
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v v, : "interview of customers ana other a£f ected 
' ^ of the- current inf or- 

• j : >. > -.'-.i^ ^ ■ i?/"-^^ './"• .-■ 

. ^ ' * clar rf icat^ objectives 
: ■ ■ , * jfle^ennination of output,: input; and procedures. 

;\; •' ;> .;^. v.- ';^ ; K' ?\ ■ :. : - : *y ; , ' 

-■■ ; \\! aevelc^^nt. and* presentation r ,of * alternate 

j-'v- v v- :;'y^'-:^iutions v {- y.v--; • • . : * 

Vv- ; ; seliec^^ ^ > ; . ^ 

v; "^-^ ^"".,^ approval : *and use^ a solution 

• * t - est^lxshment ^oj^p^o jec* : sche^le and selec- 
t ion of staff > c • ,/ : ' v ^;V,//-'^ ■ 

. : " .."^ v * '/ f inai pre-desigri approval and- sign-off ^ 

B. ; Design . ; The design s tagfe i s the development of the 
specifications' foe the information ■ sys tern / software , ' 
; and operations including : ' - 

information ■ system: r summary flowcharts and 

.narrative'.; - \ ' ■> , ' / \ . ;',v'.;->/ 
>■':'-..'. V* information sys tem : mid-level \; flowcharts and 
; specifibatibjis^ " '• " ^ /*'..: 

* ' manual and automated procedures: summary 
V f lewcharts and specifications , " 

? * j^r ogr anr summary : flowcharts arid ftarxative ^sum- 
mary ';■■[: \ r *'v> v -f. ■-. '•. v^- :: .^v...';""'-; . , ■ "; : ' 

* Program: detailed r flowcharts^^^^ Md- ' aetaiied v 
"/.'v. : specification^ ■ • . : v : '-..- : ;' ; ^V: : '7..y . .•• 

^ * , op^ratioi^f lowy and scheduiing: : ' 

jr ^ .■'■'..-'> externar^b^ariping arid di str ibution , specs;if iqa- • 

^ * <^^^1 i ty -assur ancfe approval \and s ign-of f . 

C<r Programming ^ : arid ^Tes ting i> ^ Activities during . this 
v . v y stage ^ include the efforts rof, : the -progranEmirig (coding) 
personrijel. Included are:; .' - 

^ " ... '*... -coding :7\'A r ;;.> • ^ 

v 1 ■ *0" . -> r sorJb^" " a m^iFgretfi and t other utilities /. - " / - \ 

* ; execution/joB control: language u " : ^v = ^- 
; v • ^ ? 30b,- s.trelun structures % ^ ' • - -'^ • 
'' *" * * coxspiies: .. " : : . ' J •'' " :> '■-> ^. ;r ; 

> * ^ebugging^ ^ f /V." : : ".. . " .->■>;/:••< 

. / ^. * " pr pgr am testing with programmer % test data 
- ;^ * ^approval;^ ^sign-of f - ^ ^ / gp : . ' x^, : • / 

3 . >Ins talla t i on/Integr atlon/Cbri^^sion/Iestihg^ Ph ase > Dur- v 
ing this phrase^ of the life cycle the ^following; activities ^ 
. : take place:; - ■■ * . ; ^- '■ v^'^o."-.-; " • . ^ . . 



O ' \. . ., - : - . - ; * . > ' " '- 7- . : ^ " * v , V; ^ . 



formal ^p|St ' 

^ o cbriveltsipn .of . ^af .f ^c^ed- . ) f il©s r^" •• and: ... autcfeatea^nanual 



V." M;,: * ^customer ;appj^aiH*arid> s igrt-^f >• . / v - ^Mv' : ^^i 

.. 4 v : Oper a t ional^Pha^se w Ttie acti^iti^v^r ihg tMs: phase axe ->-?. v . 
v; directed : towards the : effort arid in^ ; ^. 



.■>"■/-■ review priorities/ runtimes,, e£c. 

r-v^ : review 'of external 7 balance procedure^,* disttibution,' 

>.'-'••'-.'■■ V^te^;: .:"^ ^-v.-; * -V- : />^^v^:-; : ^: ^:'- = V-.V - y. ^ . 

^ ^ review of .hardware re<jbiremeotSy " - " ^ V * v 
^ > ^ >xeview\bf; ^etehtions; ; back^iip* and recovery F disas- 
, /\ ^;,y : \ ter r ecove r^ . < v ."' :'.\;. r : ' /'„• . < , 'v.; ■ '. r t s^s. . - A 
♦ review dfkownershijg^and trouble -call assistance ^ -If 
l 'y. : I Quality Sts^p^ r 



dards/are being met , , - . m . >. , 

y 5> : ; Maihtenance ^ and Modification Pha^e i The activities pei^r 
^ "fq Phase* include: .;^ ;\ ..: ^; y ; : '- — ' 

/ a y ^ production / xn&>nna- • 

- ' v ^ tion systfem to keep that ^ystesm in line with^d^part- - 
^ ment standards and, changing hardware/software^ coitffci- V? 

r,^: - : > , . : " r * ' %urationf r etcv 'Cl.^:^--^.'}' . : : . " •\ . ■ ^:;\ '^r?'' ' ■ 

w v * vu» * ^tbe ^ implementation of modification 1 "sreguests . t^>; 
' v .change^ ^add # . or ; delete t;h^ process incf spedif ieatiof^v 
6£&an ei^stin^p^iit^^ 

^ ."' ; ^ ; ^ 

; " !Hie activities described labove for eacjh phase £f ' the . r 
system. life ^ycrLe prov^te x a framework for comparing uses of 
r^^€he IRDS* • Berore^ showing^ it is necessary -f 

>"ta als6 pf the 

IRDS* v -We ^illC then illiistratedi^th^^ 
$ these ^ users an^- their uses of £be^IR§5 during the SLC- , ^ y 

l\ c 3 ^ 3k 3 ^Qfs i ng. the -rlRDS^ to - 'su^pbr £ Ihf grina 1 16x1 Sy s terns : Evolia t ion > , 

Itionship -^of - th^ ' 1^ • 
the IW)^^ :^- y^ - ■ 4 + - r^;^^'. : ^ > 'J:^^. ^-a 

-:v: v ^ :: ' ' . v^- ^' I^r ^ .^-r^ ^ i ^ •• 'dr ■ '- : • ' ' " : . ' •' 

' ' '• .:.V" : ' ' w v" ..-^ v,' . .. .•• *v ■ • s *' V. "r^ 
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. provide information, about . information systems fox 
: . ; .v-, data . contain^^i :~ -:,i;_-v. 

re^r t-on. e»istiri^ ?conai^iohs and ehyironments ' 
.*■ "support: th^ throughout 

:.;ij^^system: 04f^; cyclW " ' ' 



~ ^sup^rl -wat atjf- investigations arid analyses " . Y'---'\ 

^ Who; the -1^5 "provides support to and what kind of sup^^ 
por t it;' ; .proyides - i%:. expressed in the "following -sections. - 
This, discussion- should illustrate the wide? variety of users 
A andf i usejs of .the IRDS during the SLC phases and activities P 
*It is hbped>;that T&b^s^l through 3-7, used to - illustrate" 
these relationships.,; rwill clarify an area which A s normally 
very ambigupuSif Thelftables are presented as ^ an 'attachment 
at the end ,of^ this .cnapter. . • . " '• ' 



3V3.4 Users >. of the\, 

• •• •••• v '•. j^:^ -v • ■ - . ■■' :■„.> "; -r' ^.r 

The potent ial, and?' actual- users, ■- of the IRDS - in the "~. 

development orf - iirfprmation systems' can be individuals/ but •' 

the i ntent here is^o consider them -as classes" .o& users or^ ? 
, as organizational entities. The following it«ns describe. 4/ 
'the identity of each user , and the functions .of . 'these users - 

in the - v|rious^ii3fise1s ^ ^^information system life, cycles 

a; ;J ■ ■ ■■ ' \:, : 0&<<^r ^ ' ' : :: •K;;?'-,- .' ; * ; 

:> * The. IriformatlBh^Resburce irresponsible for 

w- .managing*. ;^th^ corporate inf ormatior&resource. ' These 
-resources include -bu% are not limited- to: r j 

; "7 «4^^ta?ana' raformatiq^'; f' ■ ' ■ ' : . 

•,-7T^"/ r - 'automated data and info|if!pati6n * . " v " 
.-.f^oi^er text , and image dtta arid information ' 
- ^v^oraal corporate informations and %ts "flow * 
■.^> : : rr^^°f90*a£e i records and|¥hf orroation archiving ^^"^ 
:• : :7: ^a^pj^^ur^-^aind-f 6rniiEk^v-'-i-^^ ; V : ^^^' ''• r '" > - : - - 
._^V 'j^poij^ate ihformati^ systems ,■"•'■>■.■-. ' '^Iv* ' \i? 

• ^*e n fe^|^in^^ flow 
- «^ ^ocessing, : ^n/machine ' interfaces, ' etc.). * 



- r; *^ 'The: R#6grammer is ' rWpbiisible for deVeloping the" ' 
,.v'' coj^ tffif pr ogtams^ ns ini s ' : pr bcedur al languages (COBOL, 
^ Jt/J^/Q&t 0 '^ ' non ~E^o tfi &d l iral languages (report writ- 
^^s^^^f ile ^ . ^ '-systems, etc,) , and 

. * y^pr p^M/fys tern- generators ; (input validators, appli- 

etc.); 

^i^--'- - : ^V >;: -' ■ ' : • ■ - ' J •••• ' ' V ■ • ' • 

• ^ ^ v-^i-AJi/Vr \ ^ • - - .. ■■>■*'•:..- 



-4-" 



I inf oCTation^system^s, products^ 

ffii^^re efficient 



sch^ul ing: ^ of "the computer-related 

equipment % (cbinpu&ers ^ .etc • ) • 

— ' " the- 



; ^dif^renfc^ 

Qnterit^^ pluses of - 

'$:W$r^ are 
? - '^ cot 

iii^^ ' 

*.v The ilairitaiintef 'is a p^p^ie^ner or analyst /^sftSlttst-^' 

•••• ble for ... the j^i^jE^matio^v system while it is in the 
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r maintenance and modification phase of its life ;cy- 

* The Database Administrator is the individual Respon- 
sibly f or the: integrity oil vthe physical data struc- 
tures and def ana tipns i and- f or database perf ormance . 

* The Data; jififeihi^stratbr- ; is the individual responsible 
for the integrity of the logical data structures and 

' * The Systems Analyst is responsible for analyzing 
user needs /y ^information / flow and transformation , . 
privacy ?ind security * inf ormation processing , and 
other information system requirements- ^ 

; * The Auditor is responsible for analyzing ^aud it and 
" > control, information during "the various phases of the 

system deyeiopment life ; cycle." These individuals 
- may include audi tors r quality assurance analysts/ 
u,.- . -■ and customers. - : ~-$fl£t:\ ' . ". "\ K r .' ' ■ ; 

:.;f."' Pirograms^ are automated procedures, that may directly 
access the dictionary for dynamic use of the meta- 
data. [' <: .\( 7". / ;/ 

3.3.5 uses of the IRDS^ ■ ■ \ ; 

In identifying the potential uses. of the .XRDS, it was" 
;clear that terminology in this area is inconsistent. The 
following explanation is provided to clarify the terms used: 

.* Techniques and processes describe algorithms and 
control processes* 
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^gogBgneh^ ; their 



* 



* . 



* 



* 



deg^ 



* D tnerfiovyo^aba though ^hp. ^yg- " >. 

• • tem m ahcj procedures atfrpctied 

':;t'"-.;l>y : £be^ f lows ^an<fr processes ) arid £rodedures ; affecting ? 

•': r . *' the flows. ; .'- ; iivy ; :-- -V ■■■.■v. > • . ' • 



Data structures depict the char acteri sties of data 
and data access techniques. ; :; . ' 

Integr i ty descr ibe^— busings^^-lreaa^^ — applix^rt±on>^-^ 
ertci y constraints, including security and privacy 
requirements to insure correct! aspects -and con- 
si stency of* data. . 

Validation criteria describe r ieaai and/or illegal 
domains of values. 

Data definition generation describes the^ inf ormaifion - 
necessary to maj) data f rqm the business view to the - > 
automated view, evgwy iskelejbon for generating DDL,/ 
PL/I declarations r subschemai^v ^e.tc. 

Impact' analys is pot tr avs the information necessary 
to assess the impact of changes to the information 
system because of modification^ to the business en- 



, vironment, resource requireinents and utilization, 
system .arid component interfacing, the user communi- 
" - ty; etc/ , / v/ ; : . .. r > ■ ' - ; - ' ■ 

;*': Information^ system design provides information to 
assist:, the definition, design, and integrity of the 



total' system* 

Backup and " recovery identifies^ requirements and ^on- 
sfraints to perform system backup and recovery. A 

Environmental constraints define the r factors which 
will constrain either the development or the opera- 
tion of an information system. 

Monitor application system use is the use of the 
IRDS to ^actively maintain information on how, the in- 
formation system is being used j and who is using it. 
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* Metadata changes -identify the owner or;; fpcal-poiht ; 
- v for. IOT^inf orroa t ipii ta^£n§ure change is controlled 

* Porms vde s ign rdef ines>arid describes, all formats g^ory. v 
" r - -inputvarid^butpa^ ":'" r " ■ ; • 

* Transforations define codes- (or values) /with th^ir V 
^ . v associated meaning or text. - 

' /iv' r- -':V. : ' ■ .... •„• '.. ■, '-" /. * "'' • • ■' ■ ■' ; '.-v 

r ; ^ " Prdgran^code generation requires; the idodtimentation; 
J ^ of data definitions^ : .data-^lowr processing tech- 
"™ aiSfcr networks -to 

^ create ^program source for an application development 
facility. ■ v 

Test data generation requires the documentation and 
.-..V v w analysis of data definitions ^/aata ft ■iEIwF^prpceasil^; : . / 
techniques', 'forms designv algorithms,,, and networks 
to create test database^ test transactions, test 
plansr ahdl^est reports. \V 

Ve r si 6ns d e f ine 1 inu 1 1 ip le versions/ of the same inform 
matioru ^yS;;y y .. . . 



Tables 3-1 through 3-7 : illustrate how r the IRDS *;±& m ^used in 
each SLG phase by identifying, the type of use for' the users, 
and uses described above. / ■ : ' ^ v " 



3. 4 THE DATABASES PJERSPECT I VE v> ^ 

3«4.1 Approach. , > V ; . « .. 

: The objective "of , : this section is to conceptualize an 
IRDS in relation to -the design and development of databases, 
querying and deriving information concerning databases , and 
pxoviding operational: sup^drt .to automated databases.. This 
database perspective is also equally applicable* to nbn- * 
autofl&ted files and operations . ^ The terminology in this- 
section should therefore be interpreted to refer to both the 
automated and non-autbmated envird^pients* . ^ j^' 
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3 « 4 . 2: Users and Uses ' -orllhe tiass * 



v.- 



approach ^recognizes -three -conceptual' functions ; - in 
i; er ?^ of two -modest-global and operational. The specific? - . 
-need^of^acfa^Tnod^ "and" >kr e " 

s £eref ore addressed individually* The 31^ modrLcor-' 
porates an enterprise-oriented- diet ionarv ^ 5557^^^-/^^,^^- 



T-^r-rand - is thought of from the enterprise point of view, . 
since all data, about the, enterprise -can „be ' viewed as being 
independent of environment (manual or. automated) , phys fcal 
implementation, computer systems, of hardware. 




Enterprise- 
. Oriented 

Dictionary 
.Function 



Dictionary." 
Function ' 



Figure 3-2. Database Perspectives of ah IRDS 



The operational mode / on the other hand, is composed of a 
directory function \i and a systems specific dictionary func- 
tion (Figure 3-2) . The. directory view concerns' user in- 
quiry, information searching,' and information locating in 
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.>v.*s'..-V 



teri^^ the ■■ qpgra.-. 

des±gn^^^> multi- 
database^ , ai^L ltelj^ r e P^ 

vi r onmen t . : The^sy Sterns specific dictionary ;•> is ; r a daitabas^ £ 

!x>£:feiifc^ ioperationar needs/ 

for/ aii 1 r 
It assuiijps that - eadh: ;*? hardware system may have a d isHnct v , 
dictionary c%itliility system . u 

(DBMS} may have a ; -jBti sfc£nct ^i^ionar^ capability , l^hnd ? 
several ?stana~MbheT die tiohary capab^i ties may exist, on 
several/ hardyteife ^configurations . Ali^ough. three conceptual < 
functions have been identified^ thfey may in fact ^e 
coalesced; .for enterprises = within a * diverse^ hardware -or 
software enyir;c5fanent T Prom a logical perfective it is.^ im- : / 

iportant tp^yiew these three : conceptual functions as t>eiong- . 
ing to a single / logical , JRPS* . <j m ^\\ > \/}:\; ^ 

This conceptual approach mafces clear vthe; distinction;/ 
"between .data administrator and, database a 
tivitiesl Th£ diata administrator ;r .a<^vi^iuist be concerned 
with t£e enterprise view of the r dictionary and looking at 
data and information in global terms Th£ database adminis- v 
trtftor requirements are specif ia ta each par ticular database 
environment* as defined t>y tfife'^ysio^:^ 

theV^enterprise^ and will be^cdnc^^ physical and 

logical -aspects of the operation**^ emfcirorimenti? ,•: 

wfiioh> : is 'usually, dependent upon^^ scope of, the 

enterprise. * % , * ' " * ,'Y* : ^*f\ ^ ' ■ , 

3i4.:3 ^terprise^Oriented Dictionary ^Fuhctix)Jtt. 

In the context of the database environment of the :en- 
terprisfer the enterprise-oriented dictionary function,: 

■ * provides a canonical description of all data objects 
-/^^att&i: associations' among data objects which may be 
u ^regi^r en oflfc or utilized in databases > implemented in ' r . 
> the DBMST^wViironment ( s) available to>Qie Enterprise . :% 
Such description will include authorized synonyms, of 
named data objects and associations^ - 

identifies, aggregations of data objects and associa- 
tions/ as necessary/ consistent with the data model 
ttsed to structure the (^cpijceptual) global database 
schema/ and #hns def ines the conceptual schema . , 

— "V " ; ..... : . / . 

identifiesXthe use of ^ataS: objects in -user viewa^:- 
(external schemas) iinplCTiented in the DBMS envirqn^y , 
ment/ and x the : computet vr system ?. environment (s) v . :y. 
which user views -are implemented % ; . % ; v ^/ ; - 
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identif les. ^<^antie ^; i^ti^rilgr constraints , faeces s 
«;^'C(mtM^»and validation criteria, with respect to ' 
U data Objects ior aggregaitions .sof data objects defined 
- -in tiie cbnceptuai^sysfeein' j. ;;v9 ..• ; ;. \ ./; 

£ .^ u PP°?^7t&e; following 5 factions > when" embedded in 
- -appropriate software >*envffionments; ^ ■ ' . 

. ■^^^^^^^f^^l^pf^^^^ design—this ^ in- 
. . eludes provisions for merging user , views into a 
.>>; non-redundant : globaj.. view '.if "the design metho- 
. i dolo^ is reg^iremeht^- oriented. . 

■»• ' - m a^ping N 

.-V'' V* ~ external schemas^ in the' operational DBMS 

. ' ^environment Csj > '. :. 

* r . * - mapping the T systems vi ew to the directory in ' 

' the operational DBMS environment . .. .. , 

3 . 4 . 4 • i)i rectory Function. -7 : 

•. " directory is an organized; integrated repository of 
data .that provides for user inquiry^ information searching, 
and- information locating to determine Vhat? data and inform*-. . 
tion is -available the ^operational^ data' environment of the. ' 
organization. " A functional user, regardless of, » discipline • - 
would be able to determine whethesr^th^ data exists in the?- 
enterprise -and, if 'it does exist, 'where it is located and *' : * 
the path , tc~ obtain the information. The directory function 
provides a JCross-ref erence use* of data- whether .^It is- -..in- 
volved wit&v-the interrelationship .of the ^hardware and 
software such as /for multi-i- systems , Km 

locations (disi?^^ - 
and d if f er ent dat abase^m^agement systems; or the inter rela- - v "'' 
tionsKips of data^ such as user views and synonyms. 

Auditors and "functional users would be " the primary 
users of the directory. -The auditors would use the direct o- . 
ry to audit the functions ;arid -..uses of the enterprise^ 
: iP r i«nted dictionary* wh^ would use* * 

tiie'directory:; :^^^'a(W^is v 'br;^e;rv- systOTV: • specific diction- \ 
?fy.r In addition, f the- directory could act as~:a- controller 
or .buffer to the" user when brie' of the system specific die- " 
•tionaries" was not 'On-line. This >would provide, information 
to the user i to allow him or her to make a decision to either 
wait-' until the system specific dictionary comes /back .on-line - - : 
or access an alternate source ..for obtaining the : appropriate - 
information..- •■" • . ' *v " '■ u-->\/<?*.y 
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4, 5 'System Specific Dictionary ^ Funct ion. 



; given DBMS. - MEt •:* can~ be - --divided into the following sub- 
^ fjmcticH^v IRfi® fa- ] 

; .<< cilities required to in^iement. theses functions : ••>• ":; « :' tv 



— .... -■■-*, Describincr' databases:. 

- defining physical structures ■> '-*/.; i ' - # '= 
•j va4*W" ^ defining relationships" between physical struc- 

•• • . v*' ~- v .: tures :"-. : v ' '- -V . .*. . ; 

' * Database vef sion ' contro l ... ■■<•■<■.■■ " * ' s -" ' 'v-- 5 ^"" ■ ; 
' s ^v ^ ^^^Bf ^iSing staging aEnd siatus facilities - a ; - , . 

: -V 'Mbriitbrihg and^ analYfeincjr use J. % ' 

- collecting frequency of access £hd : ^update., 
■•■ • statistics. . . -^"v ... . , c - ; / 

- determining processing time for access and i up- 

,. ^ 0: .,^,..^date . . :■ ■-. ' ■ ' 

^, ^ - _ tracking - resource usage (central ^ processor^/ 

iri^ut/6utput> etc*J^ ?*"*' fi '" J ;• ', ' 

V - r • ~ polle # <a:ing f ailure" statistics ; ; 

: * Generating schema . and "subschema -definitions 
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accessing logical structures from v 'the 
enterprise^or iented dictionary function .; ~ 

} - generating, schema definitions , - ; 

1 T" generating subschema def initions V " : * ■ 

- generating input/output control ( parameters for 
the application programs acceissing ^ 



Implementing ^integrity " v :v -V 

storing the integrity constraint rules;.. > 
- applying- these rules, when. new database^ are gen- 
erated : "" • - • • r 



- Randomly ch^ecXlng to insure that integrity rules 
- ; are ^btr viqlated .. '.'. '/ ' 

* Acciess Constraints ; k V . ? . - 

- sorting information related to - ; '&cc6sf and update 

r; constraints for given parts of the databases ' : ■ 

-\ applying these constraints when acqe^se " arid uj)- - 
da*e requests. are : processed by the/ DBMS ' 
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* f ormafc ^ i'^r 
' applying update regies ts r ^axe 



- : -' v •; ^ > ^'"'^-r> ' ' v ' : : '. " ; : ,' - ~ ' - 'v - ' - . 

/, '* v> « **? ehc^ing^^S^-ufeer^piecified' information (e.g.; 
^: v " : schema^ and ;^ubisch^a definitions)- intb/internal 
■A.''.: V >• wqr Jc ing *f c^&ts ; arid t ah& e s ' : • 

r V * . i " * decoding^ aitte?xial working format and table in— 

• y::- format Ion *i&tcU user -^specified-, format 
; >;;".,.;;• ■■>* 7 allowing , ^eK^"S»"!to.'?i^ate" the decoded informa- 
- tion ■ ' ■. ;r . ... -,' . . • ^ 

' : v ' A ' ~> ; gen^rat ing, heceis^sacy "error and ^ w^ messages 

^ : - \ v V. 'during the encode/decode process v 

Tables 3-8 and 3-9 provider r esj^ec tiyely , a - tabular 
view, of . the ^^lati^sbips be^ween;^he user s rand tSe three 
% Iogicai v lRDS functions/ and the uses .of- these IRDS functions 
f rom'the: database perspective. 

• • • ■ ' '" * . ' ■ - 

' • . - - k '■•■'■•.•'-'*•"• 

. .... . ... ' .. - — -. .. .. _ _ „ 

3. 5 CONCLUSION * r ^ — 



: The reader of : :thi§^ should be convinced that tirs^ 

«or her enterprise. ;;need&:-:^ r ^naged information environment. 
This realization may : haveK resulted f rom continual ' exposure 
to the / ideas ; of IRM, IRDS/ data management; database ad- 
mini strat^on r : configuration Management, quality assurance, 
producti^i^ it may have be6n ah 

in^iration. -in either case r this chapter of the report has 
provided, a model for uses of an IHDS. All aspects of the 
model, however, may not- fit every enterprisers. needs or may 
hot ; be feasible or practical to implement, especially when 
• ^ enterprise initiates the ■philosophy of truly managing 
V its information environment. ^ o ' , 

The implementation of the concept of mahag ing tibe in- 
> format ion environment- should ^ ^ ERDS 
aspects presented" herein should „ undergo a rigorous 
>■ , cost/benefit analysis. ~ This analysis' shoaid : examine 'the 
start-up .costs, because the IRM^ j^ilb®bphy results; ^in a 
f ronfc^end loading of :fcb.s*Si v " -^e^l^n^f its,, and reduced - : costs 
of infonnation?. systems although ; some 

short-term benefits -may occur; depending on the situation 
^ within the enterprise. The long-term benefits can"; accrue 
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through standard izatib^ maintenance 
andt modification bf manual information sys- 

tems , : better planning and sbetter design: of automated infor- 
mation systems r and databases whic^ 

response ; to changes^^n • the- information environment, ^^aster - 
> tjead^bn t ir^tfce ar£as of E^vacy ^ 

* ;ahd:ip^perw6rlc controls, reducing the costs > of ;,cony6rsion , 
and modeling of the ^inforto 

develop a more * effective and efficient enterprise in forma- ; ; 
tion r environment. ^These vbenef its :can accrue over time; bijt 
f . they are riot f^ee. V [ m y: v - \ r - %u ■ l r 

To\ realize the managed fnformatibn environment will re- . -y 
quire" organization^ changes, the development o£. ^iser ptj>- , ^ 
cedures for all information systems,' the ^ training^ bf pepple^ 

v/ and - ; the changing of .people (both- managers and workers) to a 
disciplined approach ^r^ tiie normal reactive approach • The 
degree of change^ to^ the enterprise 4 is d^endent %h the • 
present ente^rl^ 

^y^dop^^ ^ ■ : ^ v 
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■ ■ > - -• ■ : Biographical-Sketch - 




Henry C. Lefkovits is President and Principal v Consul- ' 
tant ; pf Alpha Omega Group Inc a company that spe- 
cializes in the solution of a broad range of problems 
in the arisa. of Information Resource Management.-- He is 
the author of Da t a Die t ionary Sy's terns , * published by 
Q.E.D. Information Sciences/ which presents an in- 
depth analysis of commercially available data : diction- 
ary systems ^ and ^s currently Work-ihg on: the second 
edition of this workv/ H^ has - bel^ -consult iiig iti ' the 
field -of data: adm^ data dic^ 

tipnary \ systems/ and is i frequent lecturer on these 
subjects. Dr. Lefkovits ha^ — been . a member of the 
ANSI/X3 /SPARC Database Systiems "study Group since; its 
inception. He chaired the Data Dictionary Systems/ 
Study^Qroup which originated the SD-3/. on Info rma t ioh 
Resource Dictionary Sy&tems, and 'then acted as the- 
Convener of X3H4, ; the Technical Committee on IRDS. 
Dr; Lefkovits holds B. A. and M. A. degrees 1 ftc^ the. 
University of Te^as f and a' Ph.p. : /in mathematics ffrom 
Rice University^ , .->v * ■ 



PARTICI^AMfe 



Susan Bidwell , Henry Lefkovits William Perry 

Craig Cook;- • Reikis Leong-Hong : Zella Ruthberg 

Tom Fitzgerald . .Mike rMeyer Dennis Shaw 

George Gajnak Richard Mixon David Vincent 

Scott High tower • . ' ♦ Ron Voell ^ 
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•-K'tV^s /-i^^i^st; agenda Item/ °the panel on IRM< Policies $and- 
Goi^ Jto agr ee ^ oii a v wbt k ing defini t ion of Infor-: 

mat ion Resource Management. Such a definition s*as 'required 
to .set : -'';£h^ for the;work of the panel 

and to giy^ the pr ope r ,pe r spec.t i ve t o; : 1 h e i n tegr at i on of the 
wide-ranging techriolo^i^ af^^ sers f V and areas of expertise 
that cbnvefge i n IiOft;^ ^? 



4/2 DEPniITION OF IBM 



information Resource Management ig^wh atever " pol i- " : " 
'')■'-.'■' ■• oy^ action, v or procedure cone eoplng information* 
, . (both -automated and ^ manage- ; . 

■k "i • - Jnertt egtatblisKes tQ//serve the overall . current 

: ' an^ f uture 'needs of the 1 enterpr ise^ ; ? 7 Suclx poli- ^ r. 
; ° 'cies> etc> / ^ould include considerations of >aval- •...> 
7 labilit^/v-tlmel Iness ,;:; 4 acibur a.cy 'f ntegr ity "P* iva— " -7; 
cy> security/ audi tabil ity / ownership/ use/ and : ^ 
V-'.'-^cost^ef fecti^eriesf^^^^^ ' ; v\i" '-' v " V -. > : .~7' : ": 

.}• ; ^ ; enterpr ise-wide- ria- 

tijie*^ inf 6r»atibn policies/ acr; 

tions r and procedur es in. order that cla t a can -be tr eaffkd as a 
true v r^wrce:„ofi^e^^ It ;alsb jfef ledis .,. the pri-^ 

mary shift o£^T3S^>^ design 
methodologies €o" da^^enter^^ design methodoTogies . ; v> 

This i cjef initic>h:> upon completion of 

the; work, of the' panel and a general consensus existed as. to 
its usefulness and proper focus on ^"the problems that Vfere 
discussed. / - " 



4^3 SYSTEM" LIFE CYCLE 



t The scope of IRM and its impact extend into a larjje 
rfumber of operations^: {^f an enterprise. Since the work of 
the panel was limited ^y^thg. .relatively short duration of 
the Workshop/ the decision was jmade by the panel<members to 
7 limit their considerations to. "the analysis of IRM impacts^ on 
theC area of" computer-based systems.: In ordBt:}^ h <Xg^o^Si, : 
the >rark;,t6 be done and to: properly highlight the 1 \aj^£i^^ ' 
' , bility: of IRM concepts- throughout the life of such s^trems/ 
r it washed ded to adopt a ^particular: definition of a System 
Life Cycle (SLC) and to categorize IRM impacts according to 
its phases. 
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ISM phases were adopted: 
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.* • 



" s Determination 1 Phase consists of de- 



■ Regain 

Lripr " the ^aser-vtsible. functionality) including 
lata .elements % required; . : ^ ' s ^ 

The Data/System Specification Phase consists of ; 
translating the results of the previous phase. into 
a^iimplementable ' specification.: This phase includes 
p-jv logical . database design. The phase should also ' 
address integration plans in the sense . of what is 
done - about existing systems and data that will be 
replaced or interfaced within-tfee hew system. 

e Database/System - Pes ign ^Phase consists' - ,of de- ' " ?' 
iled program designs and , specifications and -physi- * 
cal database specifications that will achieve the • - 
functionality outlined in the previous: two phases; 

The Construction/Testing Phase consists v - of program . 
and database, ^implementation coding and unit testing. *. -- 

The Inteqra^^^System Testing Phase results in a 5 
system xJeadj^&d be- placed in. operation. ' * 
■ ■ ; '• •./ v • . V ,:.'•"*' 

The Installation /Operation Phase , is 'the introduction 
and then- routine production^ use of the system. 

* 33ae Maintenance Phase is routine- repair : of: th» gyg- f$ 

. tern. '"' ' ■* v.-TW v . • 

"* The^Enhancement Phase is the- addition of : new func- 
tionality resulting? from use Uof the system. '%• 

* The Termination Phise is &e archiving, and ^tjermina^ 
tion of production use£ of the°sys'tem* * 

* 4.4 ORGANIZATION OF THE PANEL : * ' ^^7- ' ..y\. 

. .The members or the panel ha<l been drawn f^om 'both the" 
technology '-sector arid the intefcilai auditii^tfZofessibriV It 
was decided that* the value of the work wdtad^^e enhanced? if 




ferent but complementary, missions 



V 



Y ~: il*e tec^oiog^ {gr pup was etistged • wl£h: v identifying is-v 
sues associated with, computer-based tool^s which are applica- 
ble and available to' support individu^^is^ from a 
de^eloper^s ^oint of view>. V.J\.'.. ~.^ "&fjf : : - . J.h 

-■ • • — . ■ '• ■ .. ■ ; - ' V, # : y : ./ -A ; • «' - 

The emphasis' of thie auditing group>,was to ex p lore the 
exposures ;1that existed in the variouj^SIiC -phases arid to sug- 
gest tqdls^^ risk of 
. these exposures ♦ " . ■ * • 'M&^'^r J \ :~ V ' • 

, v Jv i Both groups were responsible^^p^de^ 

- pbliciesr required del " 
^ani&ous SLC p^as^su 



ing 



In the final forking sessi 
presented its findihgs-and a con 
limited time avai lable . to each 
tive lists to be prepared/ it 
plete overlap between the respect^ 
The analysis did however |r4ye^ 
procedures; that IRM vquld deyeS^^ 
identified, r 4ft such/ - th4 g$$^al 




lists "of 



bricerns for the / 



each groiip : 
,v Since. 
:dfc fallow 
;3expected - that 



development^lbf^IRM procedurW 

risk* exposures that were present in- tfee^SLC pnases. - 

In - the* following, - the jEindin^^ the pai^F: r ^are 

presented. > It must be 4>6inteid y^^^^:^^:Jise of Bifction- 
ary Systems as* a tool, is* not it -was^ffelt " tBa;t_ 

this # :wpuld occur in^€£e*w6rk pf^^^^^w^kshop panels. In^ 
steady the bindings wifr^ more on * IRM- 

relateB issues.: ^ ^ ^ 

'.'4.5 IRM 




ngsx^wg 



inblus ibn was 



*TCY . ^COMMENDATIONS^ 



The pajfel developed a set of IRM policies foi^. a Hy- 
pothetical*:^ erite^ri^g* Thpse' results are* grouped in the 
following^maiper:- . • 

* > Furideraent^l; IRM policies (Sections 4.6 -*4^7) 



^. rRM. policies applicable across ( SLC phases (Section 



4.8) 



IRM policies applicable to individual. • SLC phases .... 
•; "•** " (Section 4.9) . .. '• . \' • ?■. ^ 



The results presented are intended to be representa- 
tive; v in. no ^instance does-" there exist the in5>licat ion. that 
the^;results are exhaustive. ^ i- ? 



0 
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4*6 FDNDft»flBlrt!AL I?M POLICIES . . 

The panel proposes - the following fundamental irm poli- 
cies* \'y , ' * . :: : " ■•>'•'• 



*r There will ^a^?^i-a teg ic System Architecture ~ Plan 



for -the enterprise 

V ^erewral^^ Plan which 

considers j sfibrt-^. ai\j3 long-range cost* aspects of 
maintaining enterprise data. ^ JKt- 
■i ' - w v. - .. -1:.'. -. ' -^BP' . 

* There will be Guidelines for tfae use of database, 
• . ■ .- • ' ■ management systems, languages, networks , dictionary 

* > systems, hardware, and other system components. 

* There will be a Data Standardization Program. 

- ^ • . n_. . c . .->.■ / 

4J7 STRATEGIC SYSTEM ARCHITECTtf^E-ANI) INFORMATION 
Z. PLANS . . -V* 

The* Strategic System Architecture and Information Plans 
constitute the A nucleus of the documents called, for by th4 
Fundamental: IRM Policies; The panel did not discuss thfe 
specific conterits of these documents; however, *it is feljt, 
that the present report will be more ..meaningful if a more- 
det&fTed d^agsiption of them wer^e included. What follows is 
an outline and brief d^criptibrf of each^apter <which can 
be 9 considered ' representative, of the tiature of these docu- 
ments^^- " '■ , i 



-53*" " . .^"',v . . 




PURPOSE OF CHAPTER 



4 * 



6 



. "IRM 

Goals: ■ 



IRM 



Data* 
Resource 

Modify y 



* Enterprise 

Event 
f Model 



1 • Management overview. 



Description of organization ^ terms 
of fiigti-ievel enterprise event 
model (normative) . 
Diagram of high.- level da.ta resource 
model (normative) • . / . 

feu&i^ ancl goals*. 

— — — 




^33£^§Se'ement on goals and, 

h are not dependent 
f tware r or ; 
kage commitments. 



i • 6 Describe the environmental IRM 
^in4.tia£^fes. ^ 

Desctx^ support 
^initiatives (application areas) . 



Diagram and descr ibe the conceptual 
dai^i^fel $ofr the Enterprise. ^ 
'Outrii^'pian for model refinement 
and translation to. target database 
design and physical database/ 
file schemes. - 

Diagram ""'tl|^^utreH^ %vent model and, 
describe, tt^^^3^hning-«. control/ 
and ■ ;qpe^^^^^^ie^ents .-for . . 
the eaj^g^^^Sf^"" 

Outiih^l^lSs^for model refinement^ 
and collection of cost/benefit 
data ,for each event. 



2. 



1. 



2. 



1 Description of current EDP system's 

7 in operation and. development. 
2.: -Lists of current hardware installed. 
The technology forecast for 
>?S -■' predicting impacts oh the enterprise 
for the - next 5 years • 1 
4/ Glossary of^terms used. 
► 5. Bibliography and inferences used. 



. are 

f^: around >nte^^xse 



purpibses : int inoael ihg the u 



lOttr 



*v The eriterpr is^ ^cost , produc- 

tivity improvements r arid other-org^izajeJbnal bene- 
^f its on specific .business practioesL ti-e. 



the 



on 

l^vfejritsl^ 

The event modeling also facilitates ofgaiiTzational 
development: processes to occur ; in^ 'rierutral discus- - 
si on env i r oninent ich is riot : tied to existing 
departments and^pplications r ^^^ ^ ^ "■■ 7 

The^yertt modeling ^ also facilitates' planned migra- 
tion of current larger batch processing* systems into 
^ systems! : (where- appropr i—. 

_ate)2 f £ ^Each*of the neV; support abdications will be 
^seEE^^nd%ig^a fron* a development viewpoint, but 
feeSjlp^ ^central database (where ^ ap- 



n would be a collec- 
?»s^(pbjectiyesf mile- 
to carry out the Ar- 
on Plan could be- in- - 
efcfcUre Plan itself. or as 
tiding on the planning and 
"iicies of the -enter- 




project 
prise. 
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4.S~- IRM POLICIES APPLICABLE ACROSS ALL SLC PHASES 

-r*-..- ■ ■ . .. — 

ie panel "discovered- thatC there are a - small *gr oup of ' 
policies which are not fundamental to the overall success- of ... 
IRMr but nevertheless apply across all SLC phases. ' These 
IBM policies exist, in the following areas: 



r 



$ Project Management 

* Configuration Management 

* Metadata Manag[ement* 

* Documentation Manag1|^nt 

* Review Management ' * •* 

F6r each of these policy areas subsequent sections:::^ 

or list; deliverables f appl icable* computer-based too^^^9ri^ 

cerns about tools, and recommended IRM control pol icri^r' "T 
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• The management ^policies and tools for .projects should 
be integrate* with the other a^ects-of IBM» 

a*- Deliverables ; : T : '\ ^ t ::: : : :: • Vv, 

• '-Estimation -aids- ' V..- -. "7 • * :. w^^^M^^^ 

/ Planning^ ■":■■•■-.'.,. 




OrganT^l^lQfi^tl de\celopment aids v . 

,***"" ' . • • • * ■ * ■■' **- - - 

b. Tools ; . "x V- 

- v Automated project management and estimating tools 
. (e^g. PC70, PAC-IIr etc.) ^ : 
; Data dictionary ""system - " 

c. Concerns about- Tools ; / 

: . Project management data must integ-rate into enter-. 
prls£ dictionary system* 

d. IRM Control Policies: 



IRM requi^lstan enterprise policy regarding specific 
project* management data and processes. 



4»8»2 Configuration Management* 



Configuration Management "(CM) applieis software en- 
gineering-principles to pinpoint responsibilities for main- 
taining software and hardware baseline inventories and all 
changes tb^felle baseline. CM requires^both- policy direction 
and integrated tool support*- - ^' ^ : ' " ■ r * 



* ■ f 

Del ive rabies : 



Change contxol aids* 7 

Software/hardware baseline inventory aids *" • 

Status accounting which izixes * individual responsi- , 

bility for actions and states 

Pointer system tp baseline references and documents 
not obtained within "the CM system .'\ 



ERIC 




^Status accounting packages (ANMP) • 
... Data dictionary systems 

• Source and object library parages (e.g. ^Librarian, 
rPanvalet, etc. ) . . 

c. Concerns ^^bdm^Tbols : - - "~ * - 

/ Configuration management data must integrate into 
enterprise dictionary system. 

d. IRM Control Pol icies T- - ^ ^ ' 

• Any change/^to baseline requires passing throi^fe^. - 4 
chauage contfbl procedures^ / 



4 . 8 . 3~ Metadata Management. ~ 

The use of computer data dictionary systems is expected 
to be the main integrating tool of IRM. This dictates that 
IRM policies and procedures be set up> to manage the struc- 
ture and data content of the diction^2i; itself . -j^ 



Del ifrer ableS : t ■" ^S^?; 



Data definitions 
Process definitions 
Environment definitions 



b. Tools: 



Existing, f irst-generatioti^-dictionary systems (e.g. 
Data Manager , UCC10, etc. 




6 



Proj^fi^d second-generation dictionary systems <c^ 
^ " ^ r tools (e.g. PSL/PSA, etc.) • 



about Tools: 



Automated tools must be friendly to users. * 
. Metadata management must not - disrupt the v on-going 
" integration support of the enterprise dictionary 

system. "*V ■■■ v .v - - . g J, 

. Multiple ^sites/systems must be addressed, t * C; 

. Security of dictionary systems needs to be strong* 

• ■ * 

d. IRM Control Polic 



All metadata is collected^ and documented . according 
to enterprise standards.. ■ 



i ..-.to 
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4*8.4 Documentation Management. . f 

V Software and system documentation is a critical aspect 
5 of maintaining a viable IRM environment . I KM tools and pol- 
icies are needed to manage the documentation creation, 
maintenance, and retrieval processes." % s ^ 

~ — ~ r- " "v;- - ; ■-, - — ■ f\ * v . — , - , - 

,:..a. Deliverables ; ^ * 

. .Development and maintenance standards on-line (e.g. 
- \forms,^^thodologies, vexanplesr.-- e"fcc.^ v. • 

.'Word-processing input/edit features Jt^^ake^creation 
a ' and maintenance of documents, easy ahd^controlled for 

all users (authors, reviewers, arid 'readers) ® " 
^ . Documents (manuals, 1 specif icat ions, etg .J 

References to documents not contained;', within the 
system itself " - ■"' ' 



. ^ • b. TooT^ ^^f^f 



■ . Wc>ri^pg^e^sors ' : ~ *. v>- ■'■>'*v* " - 

/•./• • Text-^3itprs .., ; • \ ;■" . f ; . : " ' ^ 

^ . . Language conversion aids (etg*. cpmpiiers> interr- 
^ ; ; " :• ' preters, etc. ) ;: ; ' : ; " .- 

f - • Syntax checkers -for languages o - r f ; * ; 
% • Standards checkers f or - l^guages and documents ^ 
System analysis/deisign^methodologies ^ W-.;-; 
Graphic/ aids ■ .'.--/ ■ ' ' 

'-> : f Electronic mail and teleconferencing aids- 



c. Concerns about Tools; 



Textual data creation, "maintenance/. >aiifl s ^i£Srieyai 
must be integrated by' or "through ; the enterpciise dic- 
^tionary;;^stemV : ^ r * " \. r ' V"?^- " : .^ r - 

Where ^o . the language „ converiion ; aids : and syntax 
checkers, belong? .A*""*:- 
Where does configuration management 'stop and docu- 
mentation management begin? ■"" " 

d. IRM Control Policies ; . * 

. There is a baseline specif icalipn of what consti- 
tutes documentation (i.e. most:^pproved deliverables 
from each^SLC phase) . ; v V 
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4.8.5 Review Management. ^ x j 

Formal/ review groups will become the governing authori- 
ty of IRM Life Cycle Management. The convening, scheduling/ 
and reporting of the work of these review groups require ISM 
policies and tools in order to -function effectively.; 

. , - . »r . :_ ^ V . ■ - . .',■■> -. . ■ x - . . «. • . . -. ■ -• * ■■ " - a • L 

,a. Deliverables : 

• " ~ — ■ — ; — ■ ; & 

Review schedules (participants, time, place, agen- 
das, etc. ) 

• Approved certification of baseline documentation, 

software, and hardware I 
•\ JleView and exception teports : ^ 
. ,, GO ,, /"iro-GO n decisions oh key milestones ■ 

b. Tools : : r Vyi % ' 

. Audit packages- (operational systems) 

. Verificatiop?^d5validation aids (development sys- 

4:ems) " .-^S^^^r.; ■;. ■ „■ . 

Standards ^iiplaahce checkers / ^ 

c ^Concerns about Tools: 



■'. ■ Review management data must integrate into /enter- 
prise dictionary system. 
SLC review management tools are needed. 
J • Better audit tools are needed to cover a broader 
scope (e.g. privacy, security, cost, data indepen- 
dence, redundancy, conversion, etc.). 

d. IRM Control Policies : 

Jo system may change -state (i.e. proceed^o another 
JLC phase) without a -"GO" decision properly docu- 
x ^nfeented under the Review Management procedures. 

■ % - • " " . ■ • " , . ■ ■ ' 

4.9 IRM POLICIES FOR SPECIFIC SLC PHASES ^0 




The same categories are given bi^^^^tbr policies and 
tools applicable to specific SLC phases. In addition, lists 
of "concerns and exposures for auditing individual activities 
withiji phases are given.. The phases described are: 

* Requirements Determination Phase « 



Data/System Specifications Pljase;^^ 



* Database/System Design Pttase* 

* Cohstruction/Testing, Phase. 




-Snt^ration/Sy^ 



4.9 



* Ins^allatio'n/C^eratidjS^^pse ^ 

* Maintenance Phase v 

- ■■ •*■ '» f .-.*■. . - 

* Enhancement and Termination Phases 
>1 Requirements Determination Phase. 



This phase initiates a new SLC^project by systematical- 
ly documenting and obtaining approval of user requirements 
for the project. 

a. Deliverables ( Data . .and System Requirements ) 



ft 



. Data/data structures J 
% • User^visible "function? statements (including user * 
manual and user-visible \error codes) 
. Environmental statements and constraints :V: 

b. Tools ; . , - . I" 

•^^J^^ticjiary: system features to compare strategic plan 
- ^ and system requirements state- 

ments ' — r ~*~^ " | „ 
. Automated requirements tools 
~ .Graphic entity-relationship diagram aids 
. Dataflow, diagram aids 
. Data event/data task model aids 

Structured analysis aids (e.g., BSP, SADT) 
Organization chart* aids ■ * 

. Transaction matrix aids 

- . ■ ■ " - 

<^.^ Concerns , about Tobls: 

Requirements data muk t ,inXegrate\_inta enterprise 
dictionary system. 
. Better requirements tools are needed. 
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&• JRM Control .Policies : 

System requirements will be cotei^s^nj/' with the 
strategic system architecture plan. ^^r 0 ^.. .- vV 

. System requirements will*be :in : standard form. 

.. ' Enterprise security> privacyf and retention policies 

— , " wfflLJaei^^ in s et ting ' r e qu i re m e n t s. — : ■• - 



e\T Audi ting Concerns and Exposures : : 

1. Preliminaij^fr to any System Life Cycle : 

vT ■■'-•r :.■ ■ ■-■ ■. * . . : • ' : k- 

Standards are in place and well documented for: 
; : . programming structures 
. systems development . 

• programming languages , . ^ 
j . cost/benefit analysis x ■;>. 

. feasibility studies 
Organizational segregation of functions is satisfac- 

■ tor Y* . ' ";" •.. ^ ' • v. . 

Training is planned ana accomplished^ 

-2. User Visible Functions: *■ 



v ^Problem definition > 
• Inconsistency ; - • - 
. Standards; ; - adbSEence 

Procedurai^adhere^ • ' V . ■ -1 Y. . , 

. ■ Volumes*: i * V ' ;; " 

- . Clarity " v " • • - ' .. . ■ ' . 

Completene^^ ^ . |^ ^ " . 

. . . Legitimacy : Y; Y:^YY.' * 

. , Reasonableness^ ;^- : v^v"" : - ' . 

3. Data De f i n it iotf -(Appiiie s to Entities , Relationships , 
~* and Attr ibu tes) ^ . : ^ ;^ 

. Iiicon^leteness' of. definition* 

. Omissions * / ' * 

Extraneous;. ■ - • > 

. Redundant * i: ■ . * v ' ' 

.. Inconsistency 
*. Units/value sets 

Sensitivity 

. Responsibility for data and access retention volumes 

•, * ■ * • 

■ ► * . -> 

• . - • ■ 0 •: • • - 
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• ■ : r ^; /w . Volumes : . : ; ; >.-. * ... ■. ' 

.-* -Response - time V /' .-;•? • ^ • 

Terminal characteristics ^ ^ 

> Security. * ' - . 

V. Commuhiciations chafStcteristicsi fc 

• v Physical environment ? * 

• Personnel (skills) ^ - 

4. 9.2 Data/System Specification Phase. ; s ' :i ^ 

- This phase establishes the overall architecture for the 
project. Subsequent detailed design and construction phases 
can be accomplished independently over time and place, in 
most cases. 

av Deliverables ^ Logical Design) ,; 

i Logical database/file design 

• Logical system design (including transactions, 

•■ fojrmsr reports, screens) <* 
.Interface specifications (integration, with other 
systems) ^ \ ; 

- : --'^^ ^ j»^ S c ? nsid ^ red (feasibility) 

+ • |^^^^e>^^pacity requirements 

/ • Database/f ile design aids ^ : ^ V '. 

je» ^reen/report deSi?^^ 
4fc Hcurdware -cpnf igi^attori aids • 
. Capacity modeling aids , v 
; Simulatbrs/applic^ion prototyping aidy 

fa jgoncerns about Tools ; v fl 

V Design data must integrate into enterprise diction- 
~ary ^system. ' -v- . 
* • t Better design tools are needed ; V 

id. , IRM Control- Policies ; - 

• J ;, U: \ *c "<• . "-" ' ' ' ■ ' , . • . v . .-, . 

. " V . Data .designs will support the enterprise conceptual 
„ -data model. . . ^ " ^ ^ ^ 

Design specifications will be in standard form 
(e.g./ dictionary).' 

A ■■■■ '." ' . ' ' 



Forms arid reports (inpj^t/pulbp controlled 
as part of conf iguratiog fflanagejfi^nt*; "\ 




*e. Auditing Concerns and^Exposures t 
v^t; interface - To Other Systems : .• 



Redundancy , 

• Compatibility > 

^ Security .-v* " : - . ^ 

• Privacy 

• Completeness 

. . • Impact of change 

2* System Design Legitimacy of "Transactions 
3. Conceptual Data Structure Design : ' 



Existence 



Reflection/adherence in%logical design 

4. Preliminary Cos t/B6nef i t Analysis : 

• Approval levels 

• Reasonableness 

• Segmentation 

5. Phasing Strategy : * 

Feasibility 

• Reasonableness 

. Legality . * 4 

• Resource availability 
Training 

• ^Timeliness 

• Manageability , 

,6> Conversion of Sof tware/Data : 

.'■*•*-*. • * • . • * * 

. Existing and target data 
Existing and target software 

• Existing >J arid target systems 

• Existing and target hardware 
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. ; This phase cbmpliSKr the detailed design of both data- 
base and processing modules necessary* before construction 
begins.. The designs must' not violate the architecture laid 
down in the jprevious phase. - 4 *^ 

~^a^ ^eTivet^^ \/ » 7^ 

• Physical database/file design : / ^ • - 
■T\ • . System specifications (including inputs, outputs* 

networks^ and hardware) . * . ; " ■ ■ 

• Test specifications v\ . ^ : 

"'• Revised user documentation f 

• "Hard" cost/benefit. analysis * 

• Conversion, specifications 

• Training plan J ■ * * "* : 
b. Tools ; • 




^ Security software {e.g. RACE, ACP2) 
. File and database optimization packages * 
. ' Conversion aids „ - 

• Test data generators 
Training aids x * v i v 

: . Structured system design aids 

c. Concerns about Tools : - ' ' " ■ „ ■ ■ 

". / Specification data iribst be integrated into enter- 
prise dictionary system. , V" 
. Better specification tools are needed.' 

d. I.RM Control* 'Policies : ■ * 

Data specifications must be validated to show that^v ° 
they support logical^ design. > ;s v 

• System specifications must .be validated to show that 
they) support the logical systiSftjt design. ^ 

. Data specif ications- must be^Kidated' to support the 
data standardization" progrcttS^ihcluding sources and 
ownership of "all data. ■■ . 1 ' ; j m %£$&~ 

-V Design data will be in \ standard' form (e.g. 'diction- '^ 
- 'ary)-. . ' . ■ .* - V* \ - . 
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Atfdlfcinaj^ncerng* and Exp6sares:fe: > 



. ^ Syst^k Specif ioations . ^ ^ -f"-'- >-?%jJS^^£? t/^^^^ffl- 

■ : Own4fship/^ccesrS5} approval: ',' -.: ■ V* " 

- Y S^6*Toriiia£t6n-^$i:strih\ited. data processing 

J Data dictionary system use:: in Operational ^system '.' . 

: : . &fcey&^%itety' A — ■ ' ' — — ■—■ — - ■ 



I/O specs ~ • • 




lima^^ance^cdnft^ -;U-£- ran £6; rua) 



. • Own er sfa fp/ac qjgs s apprc^fe ^ . ^ 
- . /Integrity^ i^-p^ ^ , - ^-^ 

v- D^ 

,J> . V Database atoihistr^iort^ J - 



.. . ^ser_tra^nxn ? . ,• .^"> .. , 

3» ^ Data / Cb^un^ r ^ ^ : 

% Backup/res tar t/reGovery bahd^liig ~ "^v- : \ • 

\\* /"Adequacy of ^ data dSmmu^catdo^ 
; • Encr^tioh re^ireanents ; ' 

.- Protocols ' ? V 

N^oi^kinsf, configuration a^ ^ ^ % : 

4, Tin^liz^ ^ j : ^ * 
^••V" Approval ieyel^ are^correct and cp^pleted. * ; . - ; V . 

* v , ^gm^tatioii ^ -'i-.. >v . . ; "'"^ A " . 

• " • - .-.-*■ . . " ■ mX: . ■■ • v - • ' jr^ . ', 

5. Security /Privacy ; c ~ 

# . v , Access" restrictions (Pa s swpr d/acce s s ma t r ix admini s- 
... tfation): , • . : : :■.■<.- Vv;. •' - .'• . 

. . Errbr^reportii^ V^-V"- 1 ■ " • •' '.^ " > '• ; 

. Sensitivii^jle«^s v * - . .. 

. Penetrati6n%^|KHng r T ^- - - - - - ^ ^ 

• Data secnirity-^K^rategy trade-offsf 

Physical security requirements , (e >g • : terminals/' 



Ext^c^al regulat ions—compliance 



£• Documentation. Rjsks r . 



• . Draft. t^Qjaanial- .7 :«V ^7* 
• . s ^*;:o^^ratibiw>iBmual " ' 

2- Global Jfeview; f 




Crpss check: to requirements . 



4.9.4 Consfcruc^^bri^Pk^q ; fixase^ ^ ? 

^if Phase A j| made less labor 'intensive V^aW^i' 
fork of tbe^pr^tedina olannf«« «v*iivi "Sa ^ 



work o? JhlSi&i^ ' e r les f labor intensive. 

the^prefeding .planning and design phaiek^tSr 
the use^of^an integrated IRM tool support » kilf^ilSP? 
testing in .^iis. . phase validates the; work of ' 
ssfcrammess." - ■ - 

• j-.^ >.?»-• " ... 




* a. Deliverables : : "-"-».'" 

' j^ n |J|5 rograins ' lo K con J ro1 statements, maps, pb- 
•' - Program documentation 

- Test data and results . " , «*. ^ 



V ^Training materials 
b. Tools ; 

: ^>,Test .data gdn^H^rs^ 
• Source .langua^Rflkr ^tbr s 
•■' Cdmpilers and^nterpirfetteS 
Documentation aids 
R Pile/database^util itie; 





<s* Concerns about T<x>lSs : 



data must be ^integrated into 
- system. ; '.■ . .- ? *^* 



enterprise- ; 
d. IRM Control Policies : 

" ' ? 0 f^ Hh K^ 11 comply with the enterprise 'data stan- 
V J^?f% project ? including dictionary system- 
. generated data definition sections. • ^ 

' G^i$g must be ^alfdated^ b to - the detailed 
specif icatioTiSy . x ' 

e ..i Audi ting Cbricer hs and ^posures t 

1» Program Logic r / 
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: -. .« Adequacy ' 4-'--' e :" v v-^. :; ;- V' ... : : '" : -v.'-fk 

: • ' *>• ^Adherence to^user |^^etoents , >.* ',-.•'„ 5 ^ 

: ^Specialized audit- Settlements • (e.g. r SCARF » tagging," -;.| 

, : • itf) • ••• s- ■ ■ ^ •••v*;^' --'. •. - " ■ ■ - . >-■* . ;^ 

• •'• •> ''' .. ■ > • .•• , •• ■ ••• .. • '■■■-4 

• - • 2-* Program - Coding : " ' : •••/....*•.. . . .--v.' . : ' 

. . Adherence to standards ~:f6i ^boding ' ^ ■ \ y 

;V — . B^s^^rice^o^s^tactiir «d Eeyiews/walicthr'oughs — 

.' Audit participation for cr^^eal functions in sfcruc.- . 
tured re^^ws/waljcthroughs-;: • :• :^*/'v% v 
* • Existence and of iin^edded. documentation .• ;j 

. ■'- .Data omissipns discovered' injV&ogr amming - >', - " , ^ 
. Resulting data^ dictionlary^^system update/modif ica-. ; 

U ' -t tions' ! -\ ''■ *;. v.- -" : X- '-"'^ V ' • • • ' f-*. -•• 

■ . S^c^bhi*4%iQn?-c|£ diet ionary£ to environment , - <^ , 

Security of libraries . tspurce,* load) • ; ♦ - 
: A - . Resolution of - desig^apgic priors . ; ;: ^ : : : v 

-Js'. 3i. UrLit/Strinq Ttestin^; ; V _*■ V V,.-*. •;' . /"' '• - 

'■'-■'££.■ ' v^^isterice-v^ ; > ■ :>.'.; is"*- --'.>v. ,^ : '4' ■ •. • 

* . Coistefiruct systems test base. ^ ' ' ; . 

^ 4 U3)6cumen-tfffaion : k ' > ' ■ ■ ? 

OT^. : i v^pinal user's ;Toanual ; : . •;•.<»;„ ■ * 1 

•:■> '■^•■ j |.if4. - Final voperaif^n^mgnual^ v v c ; .-. . V •:• 
fining 

.4 .'9 .. 5p>Integration/Svs tem Testing Phase . « ' 

- The ^.testing in this phase prpvfes that the sof twa1c^.^nd - 
" database^^ modules constructed independently under, an overall^ y 
des ign^-J-slf^lc ture **will operate -together in^ . a pseudo-, 



pt^oduct ion environment, 
a • ^Deliverables z 



• Scheduling aids . *. v ^ 

. Recovery and restart procedures 

. Training accorapli^Jied 

. Completed system (ba^eiined) "J 

Tools : ' ' ^. 

Recovery and restart aids 
. Backup and restoration aids 
*. Training aids ' 
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*■ ■< ■-. : ' " r. 



Configurate^ 



. - - * 

c. Concerns about,»3bols; - M^W- * 

Testing : and plid^ori/ ^aiayiia%t be integrated into 
enterprise dieSfci n*ar& ^wtffol 



«; v, enterpr i se dfc^ioriar^ ^yftem 4 

j3 ~IRM^onl:~r~oT~Pol icies 

..'-,".'* ":*. ■ ' — ■ • , y- -y^jv. • * 

* ' : ™e integration testing plah«-anj3 execution must TSe 

accomplished independently from unit tests. - V 



•..^•^s Auditing Concerns and Exposures "'• * 

i " ?. ^ser involvement/independent test ? • 

X Restart/Recovery t^st--all conditions •' ' 

r /fy* • Stress test/stump the system , * *-* 

* .».•>■ Volume. "test ' • I •. ••='; •• ' •» ' : , v 

|- . Finaiiiat ion of* data conversion plkns 

£ - , Proof an* baiainc&g controls.: ' ^ 
. " . • Acceptance test by user " '■' '• 
- . Security violation testing * .< 

v " :. VV^^^Sfe* of Production job contr^^angriage 
' ^ environment createion (i.e. library) 

* ^ ar ^? fil test Uf required). v \ 

4 ' 9 • 6 ^tailat ion/Operations, Pbase; - " : ^ ' " 



■:'T. 



■ . : ' ^ s ;P^ a '5e;^ ^ that 
^t^ can opera^ 



a- ;Deliveratfesr > ' : : 

^ • ; Per f orm^ce data. * ' ^ 
. Post-iristallation audit results . r ^P©' 

. ~ Trouble logs c ' 

. Running system.^. : . ' - ; 

. Attempted securi^y^i'olatibns documented 
. Production files/database; - 
. Production job ^3*H^6l language 
Production progranrllbraries .. 

b. Topis: ' * s Y ? ' 

: — ~ " . 1*- 

. .. Performance measurement aids - 

• Security packages V # 

. DBMS statistics aids * ^ 

. Dictionary system' (end user interface, problem 
track l^g/, schedffTing, security violations) 
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t Restart/recovery %xds . '<* - 7^ 

i# •* \ B^Kup/i^toration aids ^ _ - v. , . 

c. Concerns- about Tools s'"- ^ 

■ ''P . 5 ..... 

• C .Operations data,, including scheduling, must, in-"- 
>y y A tegrate^nto enterprise J <Jicti6nary systfem. 

<2k^RM-€©ri£T^l^ — — 1 — — — — 



%. ^ecufety pbl icy will be-^udited ahd- enforced . 

Performance clata will bemused as a feedbadi mecha- 
nism, for tuning, .configuration chafng^s^and fbng-^ 
*; range^ capacity planning. ^ - i V. i'~ rr '&. -~' 



e. Auditing Concerns and Exposures : 



1. Installation Review; - T-v • ;; 



Documentation of emergency modifications * 
Program* cfiange control ; \ ^ 



2. *Pos t- ins talla tltSn^Sud i t (6 months' lalifer) : 



Verify .cost savxaflr - (operations , development) . . 
.^Verij£y ghanges^to critical modules. -Sf^^ ^ r 
- * i Insi£re^u<Ji ta^lity • . * ^ -^^^^ ^ / " 

*; • Insuc^feasfbility of restart/recovery W^^^^ etn ^ e 
■ . site;iiroducjtibit. <v ... s ' Y ^^^sf^' ; ^ 

^ . Analyze change- control log. * : " . - v : T^LV ' > * >. ; 

.* Examine implemeritation of # user and operatidis traij^ \>. 

» 4^9 > 7 Maintenance Phased": ■ ■ • ■ ' - s . • ■■-^aste - ■ 

4 The amourit *6f ef fof^rfeguired to maintain a system can 
be significantly reduced: if preceding phases have followed • 
IRM policies consistently using a well- integrated set of IBM: 
tools. / Most of Jthe IRM tdols can- also be use<3 ^during the ; . 
maintenance phase. v • • ;f 

V. Deliverables ; y 'I"' 

~ - Changes— ^ — 

fe. Tools : 

Security packages . 
Coi^iguration management packages ^ . . v" 
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• database integrity checker^ 
c. Concerns about Tools ; 



«* . • '.■ ■ - . ■ - - 

Maintenance data and changes musi integrate ^in to en- 
terprise dictionary, system ~ ; : A 



d. IRM Control Policies ; 



. All. ohangj|g controlled through configuration,: manage- • 
ment (dictionary system) facilities ' 

•■ Separation of production send • 'test ' Environment 
through dictionary sy&tem facilities ; i-^ 

e. Auditing Concerns and Exposures ;.- • . : ■ : . .• 

.. Compliance with policies pn reiser - ^fhitiated/approved 
. changes . -• ~V - ■ if* .„ v ; :v, £ ■'.». '•' c • : - •• •* '• ■ 
* Identification of major enhancements ' . " • ; > . 

• . Hardware^s^stem software, corif igtfr at idn^ontiroi r" ' 
- . Per fofma^el monitoring ^ftinctlpn %r t ■>'•'■' ' ••• . / j 



4.9v8 Enhancement and Termination Phages 



The, panel considers , that the enhancement ph^et "consists ; 
of . restarting the ' SLC cycle .at an appropriate phase and oust- 
ing the -same todts and policies, as • for - a ' development pfcp- 
ject. . : ■:?>:,; ■ ;j- ; . .. ., • :■.£■)• ■ - ■ ; p ■ . 

t ■ The termin^t^Sil^p^Jconsists ^/^-B^t&l^i'-^Siiye^ro^- 



-cedures and 

tional can bej||^f recited , on 'demaffilV : .' '*v, \ /\ > 



|; 4.10 CONttUSlOlf^A^SgMMARy • * .. > 

' * An IRM definition is (proposed that emphasises the use 
of data*- as .a trne enterprisjt resource. IRM also emphasizes 
the use«of data-centered de^Wn methodologies!: - in ^ace' of 

; earlier Mocess-centered design techniques-^ 7 . 

Fundameijtal IRM policies are proposed for a hypotheti- 
cal ^orgFsmiMti the* need/ for ^tn- 
integrateq set of planning documenf ^ 




* Strategic System Architecture Plan : " •• " > # 



* Long Range lif dilation, Plan 



* Guideline 8 foe use of dictionary isystem, languages,; ^ 
. database management ^sys 'terns , and networks " '. * 

* . Data Standardi2ation)pian ' 

: A substantial .impact of— these IBM policies on all * 
. Phases. ; of v the system life" cycle of automated information 
systems! can be expected. Th£& impact will result not only 
-^h^better-cost effectiveness* JautTa^so^in^sysi^s^whfeh' are 
more satisfactory from a^sauditih^.point of yiev* TtHs "hit "' 
,,be expected that siimiia^mpac^s- will^be" fOiyid when simila? . 
u principles ar^ applied w%t»er areas WE the- enterprise also 
involved wiJj^anforma\ion Resources. "'" ■ * 
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5.1 INTRC 



This panel addressed itself to the issues; of"ii£tennation 
resource w^agemdat as thdy relate to ah understanding of the. 
qgjers V inxpmation requirements , techniques^ for representing and 
integrating the ^dividual info 

overlap between logical and physical "design. In keeping with the 
theme of this workshop, "a constant reminder was given, to tbg 
^iscuss^t^ to-e^i^ae^ti x e ro le dat a dictionari e s should pla y in 



assisting the process of logical database design. 



*The overall conclusions reached by 'the panel can be summar-- 
ized as ^follbws : - 



i) 



. ■ ■ - * 

Logical dataBase design is a complex activity. Com- 
puter-assisted methodologies will allow designers to 
cope with this problem more effectively when dealing 
with the information resources of a .large organization. 
Use of semantic; data models needs to be heavily stressed. 



TLi) 



Requirement analysis is an extremely impoijfcapt, initial 
phasje of logical database design. Existin^dols aiid 
- methodologies have a number of desirable features, but^ 
there Is no single 'techniquer which stands out, 

iiij Existing schema- design ^tecEMqn^ of com- 

v-> L> mercj^ software pr^^ tools 

her^grossly inadequate *>r np*u^£ble" at.all for * 




istic fsituatio: 
advanced its. a 




The "toor wotkb 



iy) % Data dictionaiy systems (DDSaj): wilj 
in the future for^^t^r^^dat^ase 
r looked int^ tie^opfe^K^DSs^ 
r ' as a whole *&n& 'Cc^cluaedf 1 
_ equal emphasis as tools fori 
_ * merit. Andther group identxf iedl 



ating these topis. 



^concept was 



ffer 



..-a -lot* to 
; >: A;-gr. 
'management of 'data 
d DBMSs deserve 
on resource manage- 
1st of desirable 



features for future DDSs to helpvjpi thfe design of 
databases for centralized as well -asr distributed 
environment. 

.... V '.V*'';... 

:,y) .^"A number q£^ recommendations were madffito deaj/^ith 

distributed databases and t^^allied^rbbiems of 
^ communication, control, etc. 




itieh: : to. set.*.* ; f ramework.f or discuss£6nYVfehJ> derail ■ 
~~~ ~" %s 'digc&bea in" Figure 5-t Eijs&^frl describes* 
ts.analySls activity which/ feedsvinto ipgioali^ ' 

, t.C- ^ ■ f ;• :. 
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Global Information Model 



i 



Database Schema in a 
Specific Data Model 



i 



■ . . .. r 

■* . ... ■'. 



Realization of the-Schema in* 
Giyen DBMS Environment 



EVALUATION * 
REDESIGN £ 
RECRGAN IZATI0N; 
TUNING 



.A Database Design Framework 
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Long Range Business Planning 
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itevel op En t erpri s e Requir e me nt s 



i 



■ pesign Global Information Mode tf j < [ ■— j 



r<3 



Plan ^|tefn$ for Application Areas 



-■■Jam 
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■ » : 




V 



-Logical 

^Database " ^ ., 
fop Area i v 
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Figure 5-2. fleqrffrements Analysis and Plan n 
. ( ^ in an Jnformation Resource 
Management Environment 



" 
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— : Jigo^l S^t^iows • t±e Various *;jiio4e^:of ^ information/data that 

exist lir going from a universe of;.4is<^i^ : drawn, from the real 
y world to /a database which is populated with data stored on a 
> phys ical nwichi n e-r eadable jpedium and is made available to users. 



3 



Eiguxe^-^ sj^s. the-fi analysis 
ajid planning. Single arrows shoW s equences of action while 9 
double arrows show mappings^ among models . 



~The ~Entferpt^ 

ob j ects , ' •• things activities , 8 events, policies, concepts, etc., 
which ref^t to an overall enterprise. It also incorporates at a 
-broad level: lie attributes and relationships among these objects- 
As an example, let us consider the university as an enterprise 
and 'suppose that the universe of discoursqjgfor- a given Context 
includes .the instructors, the students, 
including buildings and equipment, the. cot 
case,**the enterprise schema would include 
pins the reiesOTt associations: 



e.g.", 



a student enrolls in a 
a course is taught by 



feroom; 



each piece^of equi 
schedule; 




physical facilities,/ 
es, etc. In this 
1 the above obj ects 



tractor in a certain^ 

- • ■ 'V..' ' 

s -a fixed maintenance 




instructors teach *labs^yl£|ch are special classes 

as a lab , etc • 



meeting in rooms desij 



•ajbout which 
The Enter- 



ce a* few of the possible rel^ionsl 

..^-,,-Jfe-.a need to store data in the^^tebl^_, 

^risfe Mode}, sometimes^includes the type of processing to which 
the corresponding data is subjected. The Enterprise Model should 
contain relatively static or >invariant data which characterizes 
the -enterprise in terms of its relevant aspects for a particular 
database*. . # . i 





* The Application JRe^Sirement Models shown in Figure 5-2 
apture the dynamics df-thei enterprise-wide information by devel- 
oping requirement specifications of individual applications In 
. the) case of the above example of a university, the application 
requirement models may refer to applications such. as registration, 
£eneratipn of class rosters, faculty office assignments, clates- 
'rooat assijjnments, preparation of inventories of equipment by ^ 
buildings, departments or room?, etc. In a top-down design 
methodology using successive refinements of specification, the 
applications are describe^ at- successively "detailed levels. 

The term Global Information Model refers to an, output of the 
integration process which integrates -the Enterprise Model with . 

■ J - « . : '> -77- " 



the iJidivi^Hl 
should typxc^ 
abstractioi 





plication models . - 

^described by using; a &etta^€^7model of a data, 
as a -iobl to capto seman- 
tics of i^levant information as ^petceived by the entire user 
population as a whole. In its ideal form, the global information 
model idea is rather Utopian. Organizations where user groups 
$lace widely varying demands on the' data" and, in fact, want to 
see their "own versions" of a database which are not necessarily 
compatible? may haveSp settUT for more than one global informa- 



tion model 



_ ;\„ More and more organizations a 

their data into the .hands of 16 
• view integration aptivi 
*then, depending oh the ' 

may not. be constructed. 

a global inf ormatiSn^ mode 

mexft« • ?' ~- 




distributing the ^control of 

ups. F6r them, the - 
__. _ at the local ievel ^and 
information model may*or 
s- notr bee^ shown conclusively, that 
a must for ; distributed data* manage- 




As "shown in Figure 5-1,* the next phase* q£ ^Mxgn 'starts of f : • 
with the global informatio^i^^^ 
of the,scfrema in a specif^^ 
. the DDL; the . integrity constraints, the priva^ aad secij^^con- ^ : 
^straints and . the processing of the > database in that DtiM&^jf or . 
Simplicity wfe shall refer to this phase aa^tto vifldieatt-: d^a j fen^ (SD) : 
f : phased -It -Is obvious '££iat' th^ v jtoj.lpwing oVe^Laps e^s^^F^V • 

SD phase overlaps '-ttie^pro ' " 

whictf is responsible: for generating thj global informa- 
: tion model.* * . 



SD phase overlaps ^^^^he physiqal mapping^ of > DBMS 
[vr schema int&'the co$^j?Snding "files and/or ^tcrrage 
i^itrUctures in fiifiasl. ; r ^ " 

JEtVisT difficult to draw well jdef iited boundaries .between 
i : physical and logical database^design and further between £8^ and . 
logical design or between SD^Sefcd physical- design. 

. . • ■' : ■ ' 

. 5.1.1 Organization of the Panel .J^^.'J. 

^ To ; accoinplish: the j^est res^y^^it ^ oi g#f jdi*.- , - 

cussions ato 

divided! ^ The re^^^^^^c^ group 

are kept - within oc^^B^j^bn of this - chapter ^ far as possible . 

Group I: Req^rement^Analysis/assessment of user needs." .* * 
^ MEMBERS: Curtice, Jefferson, 

• , Kahn. ; . ; \ -1. ■ V . . 

V: 'Section 5.2 summarizes results of lieir discussion. • 



ERLC 



ERIC 



Group II- Information Moiling;/ * • .,■?: /.* " m \ 

GROUP 1EADERV XerscJ&erg. MEMBfeRS: Brodie, Buneman,. 
Housel, McLeod, Wiederhold- V - 
* Section 5*3 summarize^ their discussions. ■ 

•vV-- • ■: "' 1 ■. • ' *• •'. ~~ . ■ • 

Grp^ III: Interface between Logical and Physical Design. 
.< v •* Dph Batory: ; :.*•' * V '■ . . " ^ ■, . 

; Section 5.4 points out ihe-basiic issues of this * 
'.interface. " .* • ^.fr — • ' * \ " 1 



'Group- IV:X -Rol^ 

_ and Database Design. - ^ ^ s $ v 

tt . > ^ C ook, Craig, Folder, J 

"V > tester, Roliier Seyrrist. /- ^ 

. / Section 5.5 summarizes the overall thrust o£ their 

, : deliberations* ^ 




;'\ ^ Each groiip leader ^ s^iidtted a . rq? to ; Kava^the aftet recei^ 
ing thei* contr^uUon^ * 
ticipated only in the! dTisctosipns. MfcLeod participated only- .in 

. the r ^mtin&- This, copter is an attempt • it integrating* these 
reports./^ " ■■ - " ^ :"/ . ?' ■■? ^ v ; . V" < - ^ ' ' - 

, : ■ v- , * '' •-■•vv: ■ * . '1--. \ / 

S;2* JREQUIREMENTS- ANAItSIS ■■■ ^V-';^;\ V' ^/ 

^ 5 .2?<M Introduction ^ : S .." • . 

«Satibase design '.is a process wttiplr is dependent on a gbod ^ 
Statement df enterprise ^ (organxzation^s) requirements. In 
this section o'f the report* j»Ve are coiicerked. with requirements 
which :af feet athe logical ^ database, design^ effort; moreover, we ad- 
dress this issue fcithin'the; context of an Information Resource 
Management (IRM> philosophy. . ' 

In order, to proceed further, we need to characterize mbre 
^^ificaUy what is meant by Inf oration Resource Management. 
The vain aspects of this approach are nas follows: * * 

* - Information is to be i^garded as a resource to t&e organi- 
zation, requiring management on a broad level. 



- The information resources should be "shared across applica- 
\tibn anS organizational divisions^ 

- Information Consistency, privacy and security are of major 
impdrtance. 

•vilata Management is to be ihdepierident of . specif ic- computer- 
ized application systems . r 
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- Computerized application systems^ must be integrated.; A 
major function within an independent business^ unit will 
constitute on^pplication system (for example, the person- 
nel function within a subsidiary company but not the » 
materials' management function^wi thin one factory). 

The - concept of Information Resource Management is still 
evolving, and the above characterizations need-to be reviewed 
with this in mind/ However* the Essence of IRM is captured in 
.the above points^/ Two very critical implications relating to . 
requirements definition follow immediately from the above 
characterization. These are: - 

a) Under Information Resource Management, the requirements 
definition activities must be undertake^ within the context of a 
top-down business planning process which has a bfoad scope, and 
relates information to business objectives. Without such a plan, 
there are no objectives for which to manage the information ' 
resources; IRM is undefined where business plans are absent. 
Currently, information is most readily related to tactical busi- 
ness objectives, although in the future it should be directed at 
strategic ones as well. To the degree that an IRM approach might 
fail, it is by far due to*a lack of appreciation for this point. 

b) While*there are numerous tasks and operations which can 
and should be distributed in a modern environment, under Informa- 
tion Resource Management the following aspects of the requirements 
phase must be centralized: 

' - Coordination of -requirements activities, 

.- Access to requirements documentation, 

- Specification of the requirements definition methodology, 

- Review and. approval m of requirements results, and 

- Adjudication of disputes. 

Note that this centralization is with respect to" the scope 
of the IRM approach. Thus, it is possible to apply IRM to less 
than an entire organization. However, as pointed out above, 
there is some minimum scope to which IRM can reasonably be applied 
For example, sharing date between two cpmputer programs is not 
IRM. /. 

5.2.1 The Activities of the Requirements Phase 

In order to better understand the role of the requirements 
phase, we need to describe its immediate constituent steps and 
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/' ■ - ■■ ■ , 

characterize ^the activities which precede and follow it in an 

idealized Information Resource Management environment . Figure 5-2 

depicts the activities within and interfacing with requirements 

definition. We; discus s~eia'ch activity in turn. ; \ - 



5.2.1.1 Construct 'Long-Range Business Plan * 

This activity, while not strictly part of the Requirements 
Phasfe, provides critical inpdts to it. -These inputs define the 
nature of the organizational mission (the businesses it is in), 
the prioritized' long-range objectives of the organization, and 
how information fits into these objectives. , Additionally, it 
identifies any assumptions and constraints which are important to 
the organization's business. For example, we might assume that 
the Federal Trade Commission will not relax its consumer protec- 
tion regulations concerning mail order businesses • Thus 'the - 
business plan provides 'inputs, in the forms of scope, objectives, 
assumptions, and constraints to the requirements process. 

5*2.1.2 Develop Enterprise Requirements Model 

• This is the first task iiP""the requirements phase. Its pur- 
pose is to provide a Aigh level description of the objects, 
relationships, and functions within the Enterprise (organization). 
- This description serves as a top-down constraint on more detailed 
requirements descriptions. It is usually, done at the outset of 
IRM adoption, working from inputs provided by the business plan- 
ning activity. Since by its very nature it is concerned with . 
aspects very fundamental to the organization, it should be invari- 
ant over long periods of time. However, it may change as the 
result of merging tw& $reas not previously integrated, (the result 
of a merger, for instance). _ 

The purpose of the Enterprise Requirements Model is to 
provide: - 

a) The set of named object types of fundamental interest to 
the Enterprise. 

N- b*) A * definition of each such ohject type including subtypes 
(i.e., the membership criteria for inclusion in the 
" type). 

c) Relationships (named only when appropriate) of fundamen- 
tal interest among the object types. 

d) Definition of high-level business functions and the 
object types and relationships involved in each. 
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For example:, ACME Hotels might require PERSON?, with subtypes 
CUSTOMERS and EMPLOYEES, and ROOMS as fundamental objects of inter- 
est. CUSTOMERS may be. involved in.seVferal relationships with ROOMS 
including RESERVATION and OCCUPANCY. . The fundamental business r *: 
function of RENTING involves these objects and' relationships. • 

• • - "•■ ~ " 

The Enterprise model focuses an fundamental^ objects y relation- 
ships and functions of global interest., jt is^ important that it ; - 
ignore details of temporary or local, interest only-., : \ It consists - 
of three activities: 'data collection,- specification, and analysis.. 
Methods, tools, and techniques to accomplish these- activities afe 
discussed in the section 5.2.2. V ". ' - . . ^ % "' 

5.2.1.3 Design (Ini tial") Global Information Model ' ' < .,; 

: — : — : : — \ • . . - . >*• 

The Global Information Model -flows initially from' the. Enter- 
prise Requirements Model. ' However, it can be expanded -in .scope 
and detail as more detailed requirements evolve from specific— ,V 
application areas . The Global Information Model differs from the 
other model in that it is" concerned with the representation of 
objects and relationships as computerized data (which the Enter- 
prise Model is not). Object identification schemes, the nature 
of the mapping between objects and their identifiers, domain 
integrity constraints and so on are in the purview of the Global 
Information Model. Its purpose is to provide top-down constraints 
on all further activities. 

5.2.1.4 Plan Application Area Systems 

This periodic planning activity determines the application 
systems to be implemented within the various application areas t 
falling under "the scope of the Enterprise. It sets the priority 
and sequence of these system development efforts, and is of 
interest here; because it sets off the requirements effort associ- 
ated with each area. 

5. 2.1.5 Develop Requirements Models for Applic ation Areas 

• . 9 * 

This effort consists of the^same three activities (data col- 
lection, specification, and analysis) as the Enterprise require- 
ments effort, but the objectives are somewhat different. The 
purpose of the Application Area requirements model is to provide: 

- the set of all named object types of interest to an applica- 
tion area, including derivable ones, consistent with the Enter- 
prise Requirements Model. * 

definitions for these object types (as before) , plus their 
computerized representation (consistent with or extending the • 
Global Information Model), plus an approximation of the number of 
instances of each object type. 



- Call- relationships among those object types' of interest to an 
application are*, consist^t 'Vith/the Enterprise Model ^ plus the 
nature of the mapping involved (oneHto-many* mandatory j etc. ) . ; 

f - information processing requirements , of the application, area,, 
including suck characteristics as output data, requirements , N 
levels of summarizatipii required, data and processing interac- 
tions,, processing frequencies an^^ and the like. ' ^ 

An ^pliratiori^ are^ involve a fairly " 

complex set, o£ integr^ii^ systems^ These systems may be inrple- , t 
mented in. a phase? appioaoh* over* a' long time period*. The interest 
of ^e application c a£eaf c requirements model is to provide data- to 
the logical database ' design, activity; ,# A logical databaise design 
ajvera area is needed' to support the Integrated' 

jsysti^^'beV developed, N 

The requirements formulation: should be both Vbottom-up" 
(from examination of detailed user needs using techniques to be 
described below) and "top-down" (from constraints 'imposed^ by the 
Enterprise Requirements and Global Information Models). The- - 
mixture of top-down and bottom-up approaches is critical. The 
development of 'a complete top-down design for the entire organi- 
zation has" proven to be too time consuming and -dif f icult — man- 
agement typically will not invest in such a large undertaking : ^ 
with "a limited immediate va]fte. On thte other hand, Information 
Resource Management necessarily implies that an enterprise level 
view be developed and used to insure the sharing and consistency . 
of dat$. We are convinced this^ cannot emerge as a result .of 
"merging" or "integrating" independently derived lower level 
views. Some 'application areas may" not even be planned for the 
next several years yetmpy. be totally involved in specifying data 
requirements. The challenge is to include' only the necessary 
level of detail in the Enterprise, and Global level models^. 

5.2.2 ' State of the Art ■ • 

The requirements phase of ;the system development" process is 
composed of three activities; - requirements collection, require- 
ments specification and requirements analysis. These activities, 
are conducted and accomplished «by various individuals in the 
organization, including system users, analysts and designers. 
The characteristics of the individuals involved are a determining 
factor in the approach of the requirements phase and the tech- 
niques employed. 

There are four major requirements approaches 2 top-down, 
bottom-up, backward-forward (output driven) and activity analysis 
(process driven) . * «• 

V 
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. A top-down approach views - the pirganization a^ a whole and 
decomposes it by some predet^rmined/criteria; This approach can 
^be used to collect information/ and/processing requirements eithqfc 
independently or 'simultaneously.- }' / ■ • ; \ . - 



. The bottom-up approach of gathering requirements is based on 
the assumption that modules or programs are .the basic elements of 
any information processing" system, j The .information^proce^ssiifg 
system is assumed to -grow i*L res£on£e to' needs usually stated in - 
terms of adding new processing requirements .or programs < This 
bottom-up analysis is based soleiy-on the definition of the, 
existing or known processing, requirements- • . ■+ 

The backward-forward approach (output driven) is based *on 
the inputrprqcess-butput view of an information system. This 
approach* is called Backward to forward since it begins with the 
identification of outputs. For ea*:h process, -the data utOize.d, 
both from inputs and internal ^ata, are : identified. Tfci? is. 
usually /accomplished -in, a top-down manner. First, the high-level 
output rprocess-input data stream is determined^ Theia tiie -6utput 
is. decomposed into its constituent data items and a" backward Slow * 
is determined, for £k*se items. Subsequently, these data items . 
are related to processes and both the v processes- .and data are 
related to the process's source of this data requirement. 

Activity analysis (process .driven) is also based on jthe : 
input-process-output model, of an information^ system. The analy- 
sis begins with the identification of processes, both "manual and 
automated. A pracess is synonymous with a system activity. For 
each process,, the input.(s). Required to accomplish the process and. 
the source of each input are determined. .Additionally, the out- 
put (s) produced by the. process aniT their destination are identified. 

5.2^2.1 Requirements Collectifta . ^ 



Before any" analyst Jbrts collecting requirements, a- require- 
ments collection plan for the system development effort is prepared. 
In this plan, the data to collect is determined, the potential 
sources for all data are identified, and a schedule for collection 
is prepared. The inputs to,' this activity are overall organization 
system plan(s), the underlying {requirements) models and organiza- 
tional practices. 

The requirements collection activity is allocated an amount, 
of resources for its, successful completion. Due to this resource 
restriction, all requirement data may not be collected nor all 
sources contacted. Trade-off must be made by the. coordinator of 
the. requirements collection activity. The effectiveness of this 
■activity is dependent on the perspective of the requirements col- ,, 
lectors (the analysts) . The analysts must concentrate on deter- 
mining what the ensuing system should do, not how this should be 
accomplished. 
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j There are four;.major data collection techniques: (1) Review- 
ing documentation, ^(2)* Observing the operating environment, (3), 
* Administep^g^questionnaires/ and (4) Interviewing pertinent 
individuals. Table 5-1 .summarizes tie, -characteristics of these 
four techniques . & ■ . 

■ 5.2.2.2 Requirements Specification aji(| Analysis ' ' 

• * * 

t Requirements specification is the activity of documenting ^ * 
the^requirements in a precise and standard form. .Requirements ' 
. analysis is the activity of determining the completeness, consis- - 
tency, correctness and validity of the requirements documents. 
The type(s) and 'method(s) of analysis is dependent- on the method(s) 
of specification. . * • * 

There . are two types of' techniques to accomplish these require- 
ments activities: manual and computer-aided.. 

\. ■ • L . . * 

5.2'. 2. 2.1 Manual Techniques " 

In manual methods, the analyst colllects the 4ata required, 
collates, continually organizes and analyses the data, and then 
^-^piroduces reports [TRH] . The data is documented in a trombination 
of prose, tables, diagranjp, flowcharts and decision tables. The \ 
basic tools of these methods are often oiily pencil, paper and 
forms. Usually, the analyst is required to spend *a large amount 
of time doing clerical tasks. t * 

r 

There are basically two categories of manual techniques. 
The first category is prose oriented utilizing both natural and 
formal language, and charts. Examples of this category are, the 
AUXCO method .[Aux] , Accurately Defined System (ADS) promulgated 
by NCR," and Analysis, Requirements determination, Design and 
development, Implementation and evaluation (ARDI) [Cou, BMT] . 
\ Th^ second category is graphically oriented techniques. In these 
techniques, "requirements are documented pixtorially*and prose is 
sparingly used- to augment these diagrams. Examples of the graphi- 
cal techniques are Hierarchical Input Process Output (HIPO) 
[ Jo^tzmn] ; Structured Analysis and Design Technique (SADT) 
[R,RB,RS] ; and - Data Flow Diagrams (DFDX [GS] . The characteristics 
of these methods are summarized in Table *-2. 

5.2.2.2.2 Computer-aided Techniques 

r 

There are two categories of computer-aided techniques. In 
^he first type, the computer is used as a mechanism to facilitate ' 
* the use of an existing manual technique'. Here the computer is 
used in palace of the human to accomplish many of the clerical 
tasks and some of the analysis. 

In the second type, new techniques are designed to make 
'optimal use of the computer's capabilities. A technique, of this 
type consists of three basic components: 
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TABLE 5-1 
DATA COLLECTION 



Technique ' 

. Review. Existing. 
Documentation 



Observe. Operating 
Environment 



Questionnaires . , . 



Interview's 



Oral responses to questions 
froi a selected sample 
of persons 



System documentation: ■ 

Management overviews 

System output 

Functional Specification 
Organizational docpentatibn^ 
• Organization Charts . 

Job Descriptions j 
- Policies, s , 

Activities of individuals 

related to system 

operation 
Document handling 
Informal communications 



Written responses to a 
set of questions from 
a large number of persons 



Good as first step in collection. < ' 
Can identify other appropriate - 
techniques and their' 



; Observed may. have biases of • 

influence processes observed, . 
. Limited to a small numbe^ of 
activities, . . 
Observation skills are not 

easily learned. 

Y 

• Questionnaire design can influence 
its validity and worth of infor-*' 
nation collected, 
Questionnaire responses must be brief, 
' • easily recorded, and unambiguous,; * 
A follow-up can increase returns, < 

Sampling allows quicker and more 
economical collection of data, ■ 
J Interview must be .carefully planned 
f and skillfully executed. - 
As a follow-up,, interviewee should 
have opportunity 'to review and com- 
ment on written interview summary. 



Technique 
ARDI 



mo 



SADT 



i 

oo 

I 



SA 



Description 



TABLE 5-2 

MANUAL TECHNIQUES FOR SPECIFICATION AND ANALYSIS • ) 

* 

Tools/Techniques * - 



Reference 



System development is described as four 

phases: Analysis 

Requirements determination 
Design and development 
Implementation 'and evaluation 



Graphical design aid and -documentation' 
technique. Decomposed system is s 
documented in terms of inputs, pro- 
cesses, and outputs. v 



PERT charts Eartman et al 

Documentation standards for . 

each phase 
• Project Management. Techniques • 

tots: Visual Table of IBM 

•Contents; Detailed ljJM ( 

diagrams ' 
Coding pa^s, templates, manuals 



Graphic documentation , Softech, Inc. 
technique:, activity and.. ' % 



Techniques for top-down, structured 
approach to requirements documentation, 
project planning, managing and evolution , data diagrams 

Definition of personnel roles 

Toprdown techniques, using directed Data flow diagrams ■ ■ Gane and Sarson 
graphs, in wMch processing and infor- 
mation requirements are integrated and 

collected simultaneously. ' . , 
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a. ) A language for stating requirements which is appro- 

priate for the user and the analyst, and, at the same 
time, sufficiently structured for computer processing 
and analysis. 

b. ) , A software package which will store, analyse, retrieve 

and display the information recorded in the language. 

c. ) A database for storing the requirements . in a form that 

facilitates analysis and the presentation of informa- 
tion required by the analyst. 

The techniques differ with respect to the syntax and scope of the 
structured .language and the capabilities and reports generated by 
the software. \ ' \ « 

>* " , • .-. ... 

There are a number of computer-aided requirements techniques; 
Computer-Aided Design of Information Systems (CADIS) develpped at 
Royal Institute of Technology of Stockholm, Sveden[BK]; Computer- 
Aided Systems Construction and Documentation Environment (CASCADE) 
developed at the University ofjXrondheim, Norway[ASS]; Computer- 
,Aided Design and Evaluation System (CADES) developed by Interna- 
tional* Computer L,imited[ICL] ; Problem Statement Language/ Problem 
Statement Analyzer (PSL/PSA) developed by the ISDOS Project at 
the University of Michigan [I SD 1,1 SD2] ; and IDEF (ICAM Definition 
Method) developed for the U.S. Air Force. by Softech, Inc. and 
Hughes Aircraft Company[BMRSP] . The characteristics of these 
methods are summarized in Table 5-3. 

When any organization is considering^the move from a manual 
to a computer-aided requirements technique ,. the costs and bene- , 
fits of such a decision must be considered. The costs include 
technique, acquisition, computer costs for installation and opera- 
tion, personnel, personnel training plus others. The benefits 
include higher quality requirements documents , improved user " 
involvement, improved coordination of the activities of the >. 
r^quiremems^ analysis process^ better access-to- ■ 

requirements , and improved system development with reduced time 
and costs. - * / - 

5 * 2 .3 Future Directions 4 

; Rapid progress in the requirements phase of system develop- 
ment will depend on the development of precise, generally accepted 
terminology and the achievement of general goals which are rele- 
vant throughout requirements analysis. 

5.2.3.1 Standard Terminology 

The development of standard* terminology is important in the 
entire database field; it is especially so in requirements 



V • ' TABLE 5-3 • : . ' 
COMPDTER-AIDED^TECHNIQUES JOR SPECIFICATION Ai ANALYSIS ;> 



ion : 



Uses structural modeling technique, to 
generate an inf oniation-oriented sys- 
'terdesignr-Generatfs-i^^^ 
code and test data from. design speci- 
fication.- , ., > ' ; . 



Provides user with PSL , a structural 
.language, to document what system • 
requirements are; PSA programs are 

. used to create, 'analyze and< generate, 
report from the data base of PSI ' ■ 

■ specifications. .'• ' 



Uses forms-driven graphical technique' . r 
to specify entity-relationsMp-attribute • 
(ERA) models. Analysis. enhanced through 
defined rojes of analysis team members and 
'specific analysis procedures. 



Computerized Features , Reference ' . ' 

. ■ • . ■ " ' ' ' . "' * ,'.'V '• • * ', ' " ' " • • 

Design-information database International 

Implementation' code database Computer^ Ltd. 




and testiata. 



(All in PSA) v . ; ; i Teichroew et ai; 
Verify syntax and semantics 
. of PSL statements. •; - ■ : 
Create, modify M access • 



Produce a variety of standard 
. .reports 'utilizing;- four modes ; 

of presentation: - lists anj|. 
, tables, matrices, pictures,' 7 

and prose. . 



"6 



'lit' 



lylnc. and'.,*!, 
ani reporting programs fiaghes Aircraft [Sof] 
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analysis. For example, the terms ,f requirements 11 and "specifica- 
tions 11 are sometimes used synonymously, and are -"sometimes used to 
/ -describe- general and detailed documents, respectively* A + 
' ••^requi repents specification 11 may mean generality or details or 
somethim in between; Clearly, such differences in terminology > 
are apt jto lead to confusion and errors,' or to cause a diversion 
.of effort from other matters* 

5.2*3.2 'i General Goals ■ , 

The following are general goals, for the requirements phase: 

. , ' - Development of a -comprehensive methodology for the ~ 
collection and analysis of requirements in the context 

• • \ of a methodology for the whole information, system 

design process. r . ( 

■ . . ' • » • 

■ ; ~'.T m Development of techniques for recognizing errors as 

soon as possible. ' .■ -\ 

< ' i • ■ 

Development of ^incentives for ensuring that the plan- 
ning phase is^^requately performed. ' 

• > :. . ■ ' . •* f , . • - 

A comprehensive methodology must' specify precisely what 
outputs are to be produced at each step from planning through .« 
maintenance. The methodology must also describe how the quality 
of the plans,* requirements, designs, etc. is to be verified and 
maintained. In the requirements phase of the methodology this is* 
particularly important because of the difficulties in communicat- 
ing with users, the subjective nature of' the communication, and. 
very high cost of any errors, incurred during, later phases. The 
methodology shotild be adaptable to a variety of environments: 
simple or complex corporate structures, simple or complex informa- 
tion systems, sophisticated or naive users, minor revisions or 
completely new systems, etc. The methodology could bejhierar chi- 

\cally structured, with the degree of derail selected to "conform 
to the environnipnt. * ■ - - ^ 



A productive use of .rae methodology "will a^o require that 
' the various techniques and models be much easier torijse than they ' 
are at present - the systems analyst : will be co^i&^iiig a much 
broader part of the information system Ixfe cycle , and will be 
less able to. master- intricate J t^c±nical details:. In addition, .'as v.' 
/discussed later, .there Jare^ already many problems in peiEsonnei 
training. The l imi tations'* and .'assumptions of techniques and > >' 
models need to be^more -clearly documented , teminologyXclarififed, 
etc. It is also, -desirable to develop very simple techniques and 
modfels for direct operation by the user. Systems, that are menu*- 
driven, question-a^d-answer, etc.% might be easy "to lis e and ; ■>.*■ 
productive, and provi'dfe feedback; more quickly and reliably than a 
systems analyst. -Later paragraphs discuss some of the goals 
which shpuld be achieved^ to provide the technical basis for sucji 
^sterns. . v..- : ^- ;: ' "*\ - ' ' 



• - Errdrs tend to be most costly, when they occur early and are 
: . . recognized late. This is particxilarly important in planning and 

requirements because 'errors in these phases- tend to have wide- „ 
. ranging effects in later phases, and )>ecause errors are frequently 
unrecognized until the time when system integration, or testing, 
or even operation'and -maintenance occursy The people who would 
recognize such errors - the users and managers - are simply not 
involved during design and implementation/ For example, if the 
objects of interest are incorrectly identified during the develops 
_^ent_of_t±eJEnte^ 

of data elements, construction of physical database design, etc., 
can -do little to satisfy ethe real requirements. Current practice, 
unfortunately, is to* devote a* ma j ority of the resources to such 
details as data element assignment, to the detriment of the. more 
criticalj earlier activities. . 

; Errors in planning tend to be -extremely costly, since they 
affect many requirements, which in turn affect many designs, pro- - 
grams, etc» /However, planning is rarely adequate, either because 
its importance is unrecognized, or because it is a higl^visibility 
cost with no easily; quantifiable benefit, or because the tools 
and methodology for; adequate planning are unknown or nonexistent." 
The importance of an -.overall information system design methodology 
must again be stressed, ^because that methodolbgy should provide 
the definition and. jixstific&tion for the products of the planning 
.phase* ■ .■ .* . 

5.2.3.3 Go As in-yRequirements Collection 

* * The following;- goals are particular to the collection of / 
requirements: /. - . - 

Development of methods, for training personnel in 
. requirements analysis.^ m .' 

- Development of techniques which are independent of the 

* models used^in later phases of database design. 

- Development* of tools and techniques for reducing n a min g 
% problems." . *, \ 

' ^ " ; " ' ■ V / : 

./<*■ Training is particularly difficult because personnel must 
have not only the tec hni cal Skills to understand both' computer "V 
technology and business practices, but* also the proper perspec- 
tive to avoid becoming enmeshed.* in unnecessary details ,~\ particu- 
larly when building; the Enterprise Requirements and Global Infor- 
mation models. At present, training seems to be primarily con- 
fined to- unstructured apprenticeship on the job, and is long and 
frequently. fruitless. A-means.for assessing the potential ability 
of possible trainees would be very desirable ^ this might include 
<, ►psychological prof iles , aptitude tests, and evaluation of previous 
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experience.. Aptitude and extended experience in progranming, for 
example, may cause problems, for a trainee who has to unlearn \ . \ 
previous techniques* and perspective* Underdeveloped interpersonal \ 
skills, particularly diplomacy in dealing with non- technical ' 
people, may also cause i problems for : former programmers.. Person- ~ \ 
nel with extensive -business experience, on the other hand, may , 
not be receptive to requirements which do not conform in their \ 
views of how things should be done. In either case, a satisfac- 
. tory methodology is needed to provide guidance, perspective, and 
a means for recognizing and correctin g - errors during the collec- •> 
tibn of requirements. 

Current collection techniques seem to be quite dependent on . 
models used in later phases of database design. This is under- 
standable, because requirements collection often, involves the 
review of tremendous volumes of data of little relevance - it is "V ' 
very tempting to look toward la^tfr phases, and collect only the 
^data needed for/ a particular model. This may cause future prob- 
lems if the model * is changed; 'requirements collection must begin 
again, with attendant .increases in project cost and time, and 
deteriorated project .status and morale. This again emphasizes 
the importance of a methodology, particularly one which supports - 
a variety of models. ^ 

Naming problems may also cause costly iterations of require- 
ments collection, parti cu^xly if the Enterprise Requirements and 
Global Information models have not been developed satisfactorily. 
Different terminology" for the same thing, and the same terminology 
for different thiri^s, should be recognized and resolved as soon 
as possible, preferably while requirements are being collected. 
This is a very time consuming process,* particularly at the level 
of individual data elements; databases with thousands of data 
elements are not uncommon. At this, detailed J.evel, the Global 
Information model provides a very useful way of categorizing data 
elements, so that only a small number must be compared with each 
other; clearly, errors in the Global Information model are very 
likely' to lead to many more errors in the assignment of .data , 
elements-. 

5.2.3.4 Goals in Requirements Specification and Analysis 

The following goals are particular to the specification and- 
analysis, of requirements: 

Development of "common sense" analyses. 

Development of techniques f or comparing the results of 

different phases. ^ • ^ 

* • . ' * ! - ....'■>•*"■ 

■Development of techniques for determining flexibility 

or ff robustness! 1 . , . 

Development of a mechanism for easily making and propa- 



gating changes . 
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"Common sense" analyses are generally hot particularly 
sophisticated, but they are extremely valuable > They may be 
used, for* example, to -suggest requirements which the user has 

-failed to egress because they are too obvious to be recognized 
consciously . These .analyses are learned through experience - and 
are generally not well documented, so they contribute substan- 
tially, to- the length, difficulty,, and uncertainty of personnel 
tra inin g: Two types of ; common sense analyses are particularly 
important: heuristics or rules of thumb based on human factors, 
business principles, etc./ and the deduction of consequences of 

"iequxrements . The heuristics may sjaggest~tSat_a. user^isi_askingL 



for too much data, or is imposing unnecesarily short response 
time,. or is ignoring an important segment of the application. 
Such ajwlpfees are heuristits, rather, than reliable ^rbceaures , 
becadse tfhey involve matching a particular situation against an 
imprecisely defined ideal model. For example, we know that - 
inventory control involves stock items, levels,, prices, ware- • 
houses, purchase orders, ietc, which are related in reasonably 
predictable ways. 

The requirements analyst must be able tQ deduce reasonable 
consequences of requirements,- in order to 'provide effective feed- - ' 
back to the user. For example, the restriction of each salesper- - 
son to a single warehouse can* greatly simplify a database, at the 
expense of making it difficult to change to a, future environment 
of multiple warehouses. fc Without guidance from the system analyst, 
the user would have no reliable way of judging the consequences 
of arbitrary, erroneous, or changeable requirements.; ' 

A closely related goal- is the development of techniques for 
comparing the results of "diifferent phases. v Fpr example, ;the 
Enterprise Requirements Model could be compared with an appl^ca- * 
tion area requirements model to, ensure that there was no conf lift. A 
This appears to require the development q£* rather complex mM- m ,. ■. 

pings from one model. to another. ■ It is by no means obvious^that 
-there are ; non-trivial mappings which would apply to a> large 
number of different organizations; it may be' desirable . to 'haye . ' 
organi^ition-dependetlt variations of general ♦mappings . 

Another goal is that of developing* tgchaiciues for determin- < > 
ing flexibility or "robustness." The long rajige Business 'Plan, 
the Enterprise Requirements Model, and the Global Information . ' \ .„ 
Model all help to. make requirements independent 6f one anotfer, * v 
and hence more flexible. (Similarly, the logical database design 
provides independence for programs and the physical database.) 
*It would be very desirable to have some objective measure of how 
much flexibility has beenlac^eved, ^nd w^t are t±e^ of a 

lack of flexibility, if 'this goal could[ te achieved, it would ^ 
possible to attain the general goal of recognizing and correcting 
errors. at a very early* stage , before they become* the basis for a 
large ^amount of detailed work. v f / ■'■ . m 



A" final goal is the development of a mechanism for easily 
.making and propagating changes. Making and propagating changes 
within a particular model requires the development of fairly 
complex integrity' constraints on the model representation, but 
would otherwise be reasonably straightforward. Making and prop- 
agating changes between models is very difficult, since this 
capability requires the previously mentioned mappings between 
models, and probably * man-machine dialogue. 

5.2.4 ^The/Role of* the Data Dictionary System in Requirements 

I ^Ai^Tysis" . ; 

Data dictionary systems can play a -central role in "the 
requirements phase. v As a repository for the information collected 
during the first phase of requirements analysis, the DDS can . 
relieve the clerical burden of the collection activity. In the • 
specification phase, the DDS can serve both, as a tool and as a 
control mechanism. _ Finally, the* dictionary can provide* certain' * 
basic types of analyses and also serve as a database to which 
more sophisticated analytical tools may be -applied. 

5*2.4. 1 Collection S- 

The' collection task of the requirements phase, whether in 
support of enterprise modeling or application modeling, is <a 
process in which, the analyst works s with end users to determine, . 
and -document the data requirements for the enterprise and/ or for 
the application at hand. Determination of requirements is basi- 
cally a human activity in which the role of the DDS is 'one of a ' 
passive repository for the documentation of requirements. Since . 
many individual users and user groups may be involved in this \ 
task, the amount of information gathered initially may be quite 
voluminous. Use of the DDS can reduce the burden of compiling 
and cross-referencing this information manually^ Further, if 
proper dictionary entry types, e.g. data elements, reports, 
screens, etc., are 'available the use of the DDS can have a stan- 
dardizing effect on the efforts of several analysts, or of bne 
analyst surveying several users. ^ „ * 

If the data dictionary system is used as. a documentation * 
tool for documenting the enterprise model and existing applica- • 
tions, analysts can use the dictionary database for reference and 
direction during the collection phase. Data sources can be 
identified for data elements or data classes described in the 
dictionary. Existing databases which contain required data or 
applications which affect {required data can be located. This 
store of . information can aiid the analyst in selecting users to 
interview or query and in {identifying systems or databases which 
may have interfaces with the new application. The enterprise 
model contains the data class ASSETS and defines^e business 
functions and organization units interested in assets, the 
requirements for information on TRANSPORTATION EQUIPMENT can be 
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compared to' those of other previously defined assets for complete- 
ness and consistency. . *^ 

■ ■ - ■■ * ■ 

• ■.■'*' 
' The DDS characteristic most nece§*ary to support an analyst - 
during collection "is ease of use, both for recording newly col- ■•■v 
lected data and for accessing existing documentation. The analyst ~ 
should be able "to manipulate dictionary contents easily and 
should* be able to eyoke query responses and reports tailored £o 
one's needs. This ineans that the inquiry/reporting' capability of 
» the DDS must be highly selective. For example, the analyst 
should be ~able to^lo ok at on l y the names and definitions of data* 
— elemen t s relate d to ASSETS, not be f o r <^d^6o-terre^H &i s in forma—- 
tion out of larger, more general reports. * 

5.2.4.-2 Specification " * * ; . \ ' ' ' \ 

Specification involves the recording of data collected *on 
user requirements and: usually follows a, particular methodology. 
The constructs and rules of the methodology are designed to "force 
the .analyst to specify completely and unambiguously the data and 
processes required.. The interim results of specification are re- 
viewed with the users and suitable modifications lare made when 
necessary. Also, the analyst will subject the requirements spe- 
cifications to one's own analyses (the analysis phase) and re- . • 
create th£ specifications as a result. When complete, the speci- 
fications should provide a full picture of user requirements and 
should contain enough detail for* logical database design; 

The- ma j or contribution that' a data dictionary system can 
make to specification is to support the primitives, e.g. object 
types and relationships, 6f the methodology being employed by the . 
analyst for specification* For example, if the analyst is using'.-' 
the E-R model [Ch] as-a specification tool, the DDS should be 
capable of supporting objects such -as . entities , attributes, and 
relationships. In addition to enabling the analyst to record . 
characteristics of interest about these primitives, the DDS 
should also be able to exercise control over the capture of this 
information. For example, if 'NAME. 1 - -and- 'KEY* are two important 
attributes of object 'ENTITY 1 , then the DDS should reject any 
instance of an ENTITY* in which these attributes are not specified. 

Since the output of specification i§ to be reviewed with 
users, the dictionary system should support forms of output 
% suitable for this task. A* variety of output modes;, e.g. graphics, 
prose, tables, ett., should be available for the analyst to 
select the form most appropriate to his/her users. 

Additional featnaBj fcat are of interest during specifica- 
tion are controls. , Ba3 mintrols on names of objects and rela- 
tionships, can identify^ fipndancies and inconsistencies. . Con- 
- trols : , specific to the mHo logy itself, are also desirable. 
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For example, ifi^tructured Analysis (SA) [Ga] each dataflow must v 
" have a source process and a destination process* Thq DDS should 
check anc^ enforce this requirement* 

5*2*4*3 Analysis ... ■ ^ : ' ; v 

In requirements analysis the analyst critically reviews the 
specification of requirements in order to reduce redundancy and 
ensure consistency. In addition he/she may wish to examine the - 
interfaces between existing requirements/systems and the newly' 

speci^ied^data^jieedsi Questionsldf semantics amLrampleteness^.— _ 

imustrbe raised and resolved*: ~ " • " ~~ ~ ~ ~~ * " ■. ;■. ~- - 

While certain types of analysis tasks can 1>e carried out in . : 
a programmed fashion most of -the analysis is a human mental 
activity. Thus, the data dictionary system can serve best as an 
aid to the analyst rather than as a substitute -for. the analyst. 
The aid required is primarily data access and reports: As a ' 
minimum the DDS must be capable of generating cross-reference 
reports on the objects defined in the dictionary, wit must also 
be able to generate where-used reports for any specific object 
defined* -Further, it must be able to generate traces of *the 
effects of change* For example, suppose the element used, to 
identify an EMPLOYEE is changed from EMPLOYEE NAME to EMPLOYEE 
NUMBER. What is the impact on other entities., reports, input 
screens, etc.; of such a change? Finally, the analyst must be 
able to specify selection criteria governing reports requested 
from the dictionary system. It should be possible to qualify 
-requests by object type (e.g., all entities); by values of** attri- 
butes, (e.g., all 'weekly 1 reports) and by very specific object 
identifiers, (e.g., data item; = 1 EMPLOYEE NAME* 1 ) . *^ 

One type of basic analysis that does lend itself to pro- r 
grammed application, and thus becomes a candidate for inclusion as 
a DDS facility is completeness checking. .Ml definitions can be 
checked to ensure that required attributes are indeed recorded 
and all references to other object definitions can be verified. . 
Further, any standards of consistency rules positioned by the 
specification methodology can be checked and verified. 

5<2.4.4 The Development of the Enterprise Model 

The development of the Enterprise Model -involving the same . : 
phases as application requirements analysis, places additional 
demands on data dictionary system support due to the nature of 
the information represented in the model and the way in which it 
is intended to be used. Again, the. DDS must support a variety of 
constructs, e-g. business processes, organizational units, etc. 
Since,, during the development of the Enterprise Model, definitions 
wiil change and evolve, the DDS '.must, be able to record and accom- 
modate such evolution. Relationships among organizational units 



(users), business activities, and the data classes and -subclasses 
T of interest to the entei^rise must also.be captttred. Finally, . > 
the .analyst must be able .to generate reports regarding this 
information in user-f riendly formats. . . 

■To support both enterpriise arid application 'modeling, the . 
dictionary system must be able to*rec6rd i^oj^tion on, objects ^ ^ ^^^^^^^ r 
* at several levels of abstraction. For example, one must be able 
to represent the data class EMPLOYEE, the subclass SECRETARY, and v 
the* record t^e EMPLOYEE IffiCORD. Further , the DBS mfet- be able. 

to document the differences between these objpcts at different;: ; 

levels as yell as the mapping(s) necessary to go ±rom one level . : -- ■ • 
to another. Finally, the ability to check for com " 
levels as well as on within levels Would be most desirable. For 
eximple, if the above-named EMPLOYEE RECORD is defined as a part v 
of the Secretarial Skills Inventory Application, are the attributes 
represented therein those, of EMPLOYEE or of the subclass SECRETARY? 

5 -2 *4-*5 Summary 

The features required of a data dictionary system, to isuppbrt \ 
the activities of requirements analysis can be summarized under 
three categories: definition, access (reporting) y and control 
(see Table 5-4). Unfortunately most data dictionary systems have 
been developed with support for DBMS data definitions as' the 
primary objective. Currently none provide the full range of H . 
flexibility and analytic capability^necessary for Vthe : requirements* 
analysis task. Existing packages include, at best, some reporting 
features, limited support for non-standard object definitions, 
and some basic "controls such as checking for duplicate object 
names. ■ V - - ■ : - . m ' ■ ".' , v'. : "' w ■■' ' " ; " • 

Further research and development As required on more f legi- 
ble and' extensive definitional dapabilities, on user-briented 
■ . , modes of output, (such as graphics) , and on more extensive, per- - * 
haps uger-specified, controls. \ ' Tla^se'' i^T^emaits would make the 
data dictionary system a valuable part of existing and future 
requirements analysis 'methodo!ogies> V 



.... TABLE 5-4 ' v- 

, DATA DKTIOHARI SYSTEM CHARACTERISTICS AM) . 
CAPABILITIES HEEDED TO SUPPORT THE REQUIREMENTS PHASE 



* * J_ • 



'1/ 



'1 \ 



Characteristics/Capabilities Relevant Task(s-), in'Requirenenjs Phase 

. ' : »• . ' » ■ . , '•" ■ '■4' . 

, ■;■>. . •' ■ •' ' ' ■ •> ' !' , •: 

., Definition: " , ••-/,,.:.:., Collection Specification ^ Analysis Modeling 



SnpporH or a, vari ety (if infor m ation and ,, X . ", ; X 

tives. •.' ■ ' 



Support for several levels of abstraction X I 

Tailoring to a specific system development 



1 ■■■■ •• ■ - . 

00 Access: • . .7 - : ■ " ' . • '. 

+ ■ , . ■ 1 . . < "■ .' ' . . > ' ' , , * * ■* ' ' S ■ ♦ \ ; — V - 

Ease of use . : \ '. X • ; ;>•• ' _ . , X,. 

Selectivity of output requests . ' * X ' : X . . . 

Cross-reference and where-used reports .\ ' I " ■ X k 

Variety of output modes '. • X X- 

Control: •* ., ' •. • ■•• 

. . Enforcement of naming standards 1 X ■ X*'.^ • ., • 

" "* *• . .. .. ' 

' 'Verification/enforcement of methodology- ' ,% ' > ; : .i.' ;.• . ••..'•'.;..'] 

related rules" . ■ •••• - . X ' ' . '• ; X ' • ' ' •* ; ' • 
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Controlled evolution of definitions ' . * X . X . 



5.3 1KF0RMATI0N MODELING V r / ' ;, : J- ., 

5 . 3 . 1 Introduction - * / . v 

The working group on information modeling within 'this panels 
addressed three major issues:. " . . - 



V 



The Information Modeling Process , The group identified 
the basic processes involved in information modeling: 
user application modeling, view integration, and pro- 
cess specification. :T^ 

mation models may be considered as candidates for ■ 
r. inf briation modeling (e.g. [SS] , [Ch], [SSW] , [Co2] , 

[NS] , [SLo] , [HM1] , lEW}, [F] , [HWY] , [HK] , [Sh] . We ■ 
have also included several references in Section 5-6 
that give an exhaustive list of works related to these' 
. models. '. ■.• >■ ".: 

* The Database Workbench Concept . The concept of a 

database workbench was proposed as an environment to. _ 
support the database design process. The data die- 
■~~ tionary syst^^coigp tonen t--af--- the- v 6 rkhp nc h_is seen as av r 
•; - repository : of metadata about the database being (designed 
.\ The uses of metadata- in the workbench aire discussed, * 
: J \ aincL' several workbench tools are ■.gr<^osed;^y^>-^; : - : ' * 

*„' Database Communication . A growing ^concern is the com- 
munication among heterogeneous databases . The organic 
zational; and technological f actdrS influencing the dis- 
tribution of the data resource are examined. Two 
; approaches to database system communication: are pre- 

sented. The first is based on data restructuring and 
conversion,- and the second proposes a federation of 
\ ■ databases. - " . . ■ .■■/■..V - ; • ..: ' v . 

5 . 3 . 2 The Information Modeling Process > , 

-Th^iniEormation modeling process takes as input the enter- 
pris^ requirements specif ication The goal of inf ormation model- 
ing is to" obtain an -integrated, formal , 'i^lem^to^bin-'indepen^--' 
dent specif ication (the information schema) , of applicatiim-speci-. 
fic enterprise iiiformation % - 8 " v ^ : - 



The jste*p£ tff the. database design process are summarized in 
Table 5-5. ' Steps 4 through 7 correspond to infoimation nwdeling. 

f 1 The specification is integrated in that it-is the product of 
*the view integration^ rQc^ss wherein "^pte xeqo±x^&s^\pt func- 
tional* organist ib^'^uzdtis'jare ^coiciled and integrated ihto .* 
the global inf ormation schema, the specification is - formal in 
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1 : • Identify user groups . 



2: Collect -requirements J 



* * 3 : - Structure requirements 

into enterprise model and 



-appli<:a~t : ion-models.- 



5: 



8: 



10: 



13: 



1&: 



Identify 

data ownership. 



4: Integrate application models* 
' into an information model. 



Correct models. 



Define database 7 
subschemas based 
on knowledge gained 
during integration : 

Apply transactions-^ 

to the subschemas 
and estimate relation 
and connection . access 
frequencies. 



Identify 
response time 
constraints 



Make integrated database 
schema available for review. 



-Propose implementation 
alternatives (DBMS types 
or f il^-based alternatives) 



11: Compute aggregate load 
' , applied to the integrated 
' database schemaT~~-— - v 

" 12. DesigoT^promising^i^le- 

- mentations in detail 



14: ■ Apply critical functions 
to the schema for r espon se 
time assessment. 



16, 



Check Vaf selection and 
response times found 
satisfactory. 



,15. Compute aggregate perfor- 
- mance and cost iactprs. 

Select a design that . V ; . ; 

appears viable. *""•* "'. 

17. Compute performance where 
response time is 'critical. 



19: — : n 



Iterate ' l 



: ' f % USEJR ' — — DATABASE 'ADttmsmTIO^Vr -~r>^~ TECHNICAL SUPPORT 
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tKat? th& structural and operational semantics of the' information 
model are precise, and well understood. Thet i^onnation model . . 

. should 'represent enterprise -concepts , structures , operations , and 
^constraints v Lastly , ^he' information model is implementation^ 

* jjidepen^nt y in that ' mappings should. b£ ,p r ovided- to map the info r- 
mation. schema inta a database schema supported- by a data model as 
imp lemente d on a particular database mana gement system (e.g., the 
* relational model \ Col , CoZ] as- i^imfss^ INGRES 
[SWKH] , the CODASYI medel as -in^l^fenteayan IDMS f Cii]- or- SEED* v v 
[52] * or tie hierarchital^mo^l. as impl^iMNQted on IMS. ^IBM] or * 
System 2000 JMRI]).. .* ^ ' ^ . - ^ ' V 

5.3^2.1 Desirable, Features oi an: Information Model , 

o. First and foremost, : an information model should provide a v 
collection of semantic constructs to aid the database .administra- 
tor in modeling the database-spsgif ic portion of the enterprise 
model that results from the requirements- analysis phase. 

By semantic constructs we mean the structures, operations 
and constraints available to specify the semantics of the enter- 
j>*ise as it relates to the 'database scheinia . that will support user 
applications i : A iiiiii^l . reqiiirement is that the information 
0 model support the notions of aggregation and generalization [SS, 
MS]\ Further^:the model should have a sound mathematical founda- 
tion as well as'a' collection of ."orthogonal" concepts , that is, 
the modeling constructs should, be fre^of 'overlap so that: a real- 
world concept wild have^ a„ natural and unique representation in 
..the model. ' <x / . Vv V: . 

Most existing models support the notions of data, type 
% (domains), entity sets, associations, properties of bot^ 
and associations , and subtyping (generalizatibn).- Some models 
include the notion of time; with the event concept- Some may 
include time at the-? enterprise level where ; events and -procedures 
[T] -are specified. These events axS procedures Ibap to triggers 
and transactions at the information model level. 

' - \ - ' ' v-V ; ; ' .../.;'..•.. ■ : ■ , 

c Since the rojLe of the information model is to represent user 
\applicatipns and integrate, them intb ^a /global conceptual schema, 
the model should provide view integration r jnechanisms^ Moreover, 
'" 'to effectively ntfap thfe i^pmatidii model to. logical and physical 

database' structures r tte&jfeciil cation of processing requirements 
.^inessential.. Bo&' view integration and process specification 
will be discussed shortly. ,. A-.-.. \ ' 

•Finally, the information model should be implementation ; . 
independent in that its concepts ^djessjthe mpjaeliccg of the, 
w real worFd" rather than being directed toward *^ 
physical structures of a garget database management, system. _ 
Therefore, mapping " to user views (external s<aiemas)V logical j 
structures > and physical stxuctxlilps should be ptoyided. 



5.3.2.1.1 * View Integration . . :; : >v: <s 

* .'/ • Database design is ^ 

essential that the problem l>e subdivided intp manageable Darts .to ., : ; 
>reduce complexity and facilitate staged ijnpl^ent^toon. Usually, ... 
such a partitioning is performed by application ar^s {iet.g. / V;-^ " ; 
J a ccounting : " " 

V:notioi of "local views . 11 Tfre^view integration process consists 
* of combiningviocal views into a consistent global view (conceptyial 
schema)". Combining these local views* involves resolving name 
conflicts (synonyms and homonyms); reimoving'Tediindant relation- 
ships, combining entities ,^^d identifying and resolving insertion, 
deletion, and modification anomalies, .. 
. J .• .' • '. * . "* ••. : .' i ■)';.:■■ V" '"-v "-"■••«• ' " 

Data models based on mathematical functipi^ suited y.. 

for -view integration: V-'-Ihis'-is "because all data are represented 
in their most elementary form and -are not biased toward a parti- 
cular design. Also, the view integration" process is- conceptually . 
simple in that it involves the combining of .subgraphs according & 
to a set of formal rules and heuristics. 

In the Conceptual Data Model (CDM) ( [HWT] , [YWH] ) , the - ^ 
notion of "compatible sets" and "underlying value sets" is useful 
for view integration." Two sets are .said to be Vcompatible^ if 
thtfy haVe the same underlining value set. For example, the set* 
CLERKS and SECRETARIES are compatible because they have, the same 
value set, Effi»LOYEE*-NO. The underlying value set may # not be 
declared explicitly* as a set' in a schema, but an underlying value 
set^name is defined for each defined set^. The concept of compat- 
. . ible sets permits nodes (sets) in different views to be either 
merged or "connected" via identical value functions .7 

View integration must .be cpnsideftd: an interactive process . 
Sometimes the designer must be- prompted for additional informa- 
tion^ For example, deiihing an identical valuie function between 
CLERKS and SECRETARIES only makes sense if some employees can 
serve both as clerk and secretary. Operators must be provided to. 
allow the designer to merge nodes,; r^ove^redundant functions , 
and input additional assertions . Of course, , the data dictionary 
system is required to store the .information and keep track of all 
design decisions. ~ ■> , 

5.3.2.1.2. Process Requirement Specification Support 

Processing information "is needed in the °design process to 
. ensure -correctness and efficiency of the design.. J Approaches that 4 
are based solely on semantic structure information are unable to 
estimate the^rocessing- requirements of a design. ; CoTavMrsely^ 
however, designs based strictly on processing considerations Vtend 
to be flexible. Modeling of processes in the context of a well 
• " f orined semantic model is useful for: ; 





Determining inconsistencies in , the integrity assertions 
>r -(i.e. update operations are fpuniytS-V^ 

integrity rules ^stated in the information model^ • 

Determining relative access, frequencies along function- 
al paths. This informs useful to the physical 
d esign phase. -I . • -, •. ; -. : . " 




V 



Identifying deficiencies' in the semantic model, i Given 
a large number of . entity tjjp^ 
. of potential nonfunctional* rc^ 

many ,. n-ary relationships ) and subtypes (or generaliza- 
tions) th£t could be defined. The exercise of modeling 
the key! processes aids in identifying additional schema, 
'constructs that are needed, and existing relationships 
in the model ttot are nonessential^: 'X' m 

'■ ■. ■'- v' • .. ■ -s /" * 7 .-. ■ " v ': : •• '•■*••••,■;•"<; • 

Providing formal specif ication fpi: detailed application 
development. After the desigh h£$^ been approved, the 
process specification^ serves as a !s^cifieat^^ 
- • * application software? developers. i >v 

* For.. any process modeling .language to be iise£iil in database ' 
design, it is essential that it provide constructs : <tha$t obviate - . 
irrelevant details (with respect to logical database design) * 
Furthermore, varying degrees of proceduralit^Sshbuld 
to accommodate different levels of modeling (eJjg. t highr level 
specification of processing intent, versus procedural navigation 
through the Schema). : r : \ " : : - v T 

5 > 3 « 3 » T6ols for Database Design \ . . 

. Once an organization decides that data is a resource; to be" 
man aged^ and adopts database management, system tedhnology , it is 
faced with the problem of effectively managing f the database sys- 
tem, life cycle. -The life cycle [TE] can be divided into two 
phases : 1) application development consisting of* requirements 
analysis and specification, logical design and physical design, 
and 2) database operation consisting of implementation, . opera- ' 
tion, tuning, and adaptation. 4 r " , - " . ^ 

. In the above section we discussed models to deal with the 
specif ication of -the information atul processing relevant to an 
organization . A database workbench environment is needed to * 
specify, design, develop, test, and tune database-intensive" 
applications • The workbench' should^ be viewed as% a collection of 
independent yet* communicating tools. Each tool should* be designed 
for a specific part of the s *life cycle ^and should have t^p capabil- 
ity of communicating with other tools. This communica tion^i s 
important in supporting the mappings 'between the levels of -the . 4 - ' 
database design process depicted in Figure 5-1. The workbench 
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would 'rely on* a data dictionary system for inter-rtool communica- 
tion . Information common to all tools" would be stored in the 
dictionary and • could be used by the tools as well ; as by the, data- 
base designers. 

In the following sections we present a • survey of existing 
tools/ discuss th e ro le of the data dictionary, system in the 
Workbench environment, and focus ^ on the role of metadata - data 
about 'data- - in the data dictionary system. • > 

5.3.3.1/ A Stirvey t>f Database Design* Tools v . v ; ' / J 

In this section we consider some existing tools and some 
tools under -development that have appeared in the literature. 
All of them address logical jdatabase designi^^Some also address \ 
physical database design. - r ; ; . 



A. Katz and Wong 1 In [KW, K] a method is presented for both 
logical and physical database design. iogical design , uses a 
design model that is similar -to the Entity/Relationship model / 
TcETT^ The' semantic objects of the design model are entity sets 
and their properties i associations', xelationsKips , properties of 
^relationships and value* sets. -These semantic constructs are 
formally mapped into a - dfesign schema- that is a graph. where each 
node represents an entity set or a value set, and each arc repre-v 
sents a function. . • " ^ ; . ' ./ . • " 

Integrity constraints are introduced by assigning properties 
to functions,' e.g., total, partial, 1-to-l, and onto, as is done 
in the Functional Model. The design schema functions represent : 
logical access paths, referred to as access minings , that can be 
used to nayigate among ; objects. • , 

An access schema that represents thfc access paths to be sup- 
ported by the storage structure^ of a DBMS, is obtained from the 
design schema. The access schema serves as input t^ the physical 
design process . The approach is to obtain an impI(Mentation- 
•oriented physical design that is independent of. the target DBMS '- ' 
structures i A separate mapping provides th£. translation to 
DBMS-specific storage structures. . ~ ~ \ > v 

v ; The physical design process .uses tie ; algebraic stucture , ^ , 
'associated with the access schema to produce an .^dbpl^entatioh 
.oriented" storage struttUre design. let 'f : A — *B ^ denote c a func- " 
tion in the access schdpa . >The ftnurtibi* noiay have 1 , one of four 
access propertied: r { 1 >Sevaiuatea^- for each a in A , f (a> can jbe 
found without a complete scan of B>v{2) indexed ■? f or b in< B » the 
inverse of b , f " (b) cai -be f outijd without a, complete Scan of A, 
(3^ clustered - : eiem&ts one 
another,. and (4) wel^pi^ced - b^th *a in ^ind f (a) ~ in B are : * 
physically close so v that the* cost %pf 'accessing both .is less than 
the cost of accessing Jthem ' 



The method assumes that all functions in the access schema 
are at least evaluated. It takes advantage of -the total ordering 
of the othejr properties to determine tiie_^^ 

Cure strategy. A crucial rinput ^ta^^iKe^ algorithm is the ^recess \ 
frequency of the access mappings. They axe rank-ordered from L 
highest to lowest. The approach is to label the arcs of; the 
access schema vith eith er "W* f "C", or "I"; (for well-placed, 
clustered, or indexed, respectively) : such thiit the labeling is 
maxi ma 1 , subject to the constraint that the labeling be conflict- 
free ^ Four labeling constraints lead to conflicts: cluster , 
placement, path, and implied* .These conflicts are resolved by 
the replication of schema objects, and the degree of replication 
is controlled by the designer or 'database administrator. \Katz* 
[K] couches the labeling problem ks an integer programming /problem 
that is difficult to solve. A suboptimal solution is also pro- 
vided. The mappings to relational and CODASYL physical schemas 
are discussed. -,; 

B. Gerritsen, 6amblno f and Germano ■ v > 

The material summarized in this -section is presented; in fGl, 
GG, GGG] . jSerritsen {Gl] describes an environment to aid in the 
design of CODASYL databases. It consists of several independent 
yet interrelated tools;" - > . " \ 

(1) ; DESIGNER takes as input a formal specif icatioii of 

information requirements expressed 'as queries in a 
hierarchical language and produces an Integra ted Data 
Structure diagram for the application-orifented views. . 

(2) DBD-DSS [ggIv is a decision support system for physical . 
;* database design. ThV diagrams of DESIGNER and access 

" path frequencies' are inputs tefc DBD-DSS. Other inputs 
to the model are access cost, storage cost, execution 
: *^ost, and parameters relatpd to the DBMS and the hard- A 
ware configuration. DBD-DSS produces an initial feasi- 
ble solutixm for. the constrained optimization model 
. that represents the design decisions and constraints. • 
\ " The designer can vary, design parameters to improve the 

*' solution. W * 

(3) Dynamic Restructuring is a tool that allows the restruc- 
turing of the database schema without bringing the 
database of frlijie. Restructuring is done 'by marking- '•» 

\, both programs and data with Version or generation 
r ; ^numbers. *\ / r " -\ ' '■ ■ * ■ *' 

Gerritsen suggests the integration of ^the tools so that out- 
put of DESIGNER becomes input to DBD-DSS \> and that output of 
DBD-DSS becomes input to the File Definition Processor of the 
DBMS SEED [G2] . Also, the access path frequencies should be 



supplied automatically to DBD-DSS* Detailed access-frequehcy- 
calculation algorithms are discussed in I GGG] . Finally, the 
optimization. .model in* DBD^DSS might be extended to include deci- 
sions related tb. indexing, /data redundancy, set redundancy, area 
allocation, ordering' of sets, and 'media assignment. ■ ■ 

.Cv-^e -Batabase^slgn^ysten^ — - — ' ,- : , z ? T 



The design system uses a Conceptual. Data Model (CDM) fYWH] 
t ha t- is based on functions between entity sets, and a procedural 
language- (TASL) ^to^ describe processjing on CDM models . The system 
accepts a CDM "specification consisting of several local views and 
their processing requirements* and integrates them to form one or 
more global models . These are then used to generate a schema .> 
compatible with the restrictions o'f a data model supported by a 
DBMS. 

The system being implemented consists of four modules, the 
first two of which compile CDM and TASL , respectively;, i^to 
internal formats for system manipulation. *■ The next module inte- 
grates the local views into a single global view, # the conceptual 
schema. It also acts as -a dictionary for the conceptual schema. 
The fourth module generates a schema by combining nodes into 
records. These last two modules ^re interactive, ^d function as 
assistants to the designer. , ; 

. The integration module contains several features to assist 
in the design process. Heuristics are used to limit the fiinc- 
tions that thedesigner must examine to those apt to be redundant. 
It can retain multiple, related conceptual models. This allows 
the design' to be "backed up" to fcomie preceding point in the ■ 
design and re-done. It also permits the evaluation of altenia-, 
tive conceptual schemas. * ■•■ 

'The iiia^or goal of the fourth" module is to generate a schema 
wit^h "gpod performance" in several stages through a high-Ievfel, _ 
multipJLe-itage evaluation process . For example | the.: first stage t 
could 'determine the structure of the entry -popLt^^^\Mees^i:^< 
could combine nodes tb fora records, and a third could then deal*' ... 
itlih some, form of record placement. • the? results pleach stage 
could be evaluated by using (possibly) different c6£t ^functions . . 
The structure of these stages and their cost fukictiptts is cur- 
rently, being researched. * * ; -;^n r ' 

D. DEDSGN for System R - " \ • 

The relational database" management system: System R fias many 
ways "of executing an*,SQL I Cham] statement; There inay be many 




which appears best. DBDSGN is a^pTiysical database design tool 
under development at IBM Researdn by Finkelstein, Schkolnick and 
Tiberio [Sell which selects acfcess structures that 'perform well 
for a given set of SQL statements; It' combines optimizer-supplied 
eyaluaixoiis to decide i) how each relation should be ordered (or * 
• left unordered) , and 2) which columns should be indexed. Its 
input include : t he .database schema (sp ecified in the 'system 
atalogs), the queries and their frequencies, -statistics about 1 \ 



• the database relations (which may come from the catalogs), 
storage space limit, and the number of solutions desired. 

DBDSGN runs as an application program for SystenrR. It 
. extracts the cost* for executing statements with each plausible 

access path directly from the System R optimizer. By using the 
, optimizer's cost estimtes as ^ basis for a tool, ^ t^o i^ediate 
. advantages are obtained! First, the ^tool becomes independent of 
any optimizer improvements; an analytical model, for the cost of 
performing a given statement, based on the ^jcnirxent biowledge of 
the strategy used "Jby the optmizer would bfccfcme iiiiyalid^f the'-.' 
optimizer computations were altered. Secondare can guarantee 
that any proposed solution is* one that the* optimizer uses to its 
full advantage. In fact, the estimates that DBDSGN makes will 
coffcfespond exactly to thosfe made by System R when queries are* 
compiled*./ ' -. 4 * 

DBDSGN works, as follows. . tit analyzes the. basic stinicture^f 
the input queries. From this analysis, -it finds out which atoriaC; 
v costs *it needs , corresponding to a small . number of conf igurations 
of indexes. The cost .of any other configuration can be derived 
from these atomic costs. A colunmvelimination heui^s tic allows 
them to dismiss- certain indfex candidates from further consideration, 
A controlled search on ti^space of ^eal^able subsets of .columns 
is ^performed, leading to the discovery ofya set of good solutions. 

>Vi^E. v An Integrated Database Design Aid 

Jhe goal of this ^project is to devise and implement a pro- 
totype Integrated Database Design Aid (H)DA) [MlJ j Vhich allows 

. non-database experts to directly deyelojp, use, and mSatain dat^~ * 
bases. The IDDA includes facilities for: (1 ) speciifjr^ .^nd ; ■ - 
organizing databases: and the ^operations that will bej^^pplied to 
them (logical design)?, r(2) describing perf ormance; xfo^x^ents : 

c and establishing the magpinj (transformation) to a physical 
implementioit; (3)* the int^c;otoection\<^dera^ion^ of databases^ - 
As suchV the IDDA can se^e ^s /ai^envi^ 

.usiig, and maintaining personal .and office da^bases^^as well as 
-/large-scale .database systems. 

One approach to • obtaining" an ••• ^efcutable- ij^lementation . for k-. 
database with a ^ven^cbnceptiiai schema would %e to ^iiploy a V ; '• 
transformational technique with a specific kintf of trans ftiijmat ion 



i —system, and > particular set of traasfoimatibM for 
, seipantic databases aiodel. *>The transform 

a semantic schema and associated performance (estimates/require* 
. njent s , and generate as output a physical inrplementation for the 
data structures and operations defined in the schema* A trans- 
formation system of this type is interactive, calling on a 
— — desi^her-to-assis^ of refi ni ng/t h e / 



schema so that it eventually becomes executable-. 
F. The Database Designer 1 s Workbench .„ \ 

» ' ■ : - *. .; ? , v.£ ■ '* ■; 

It is a graphics-oriented decision support system for data- 
base design, .'providing designers with a' convenient environment 
for creating database designs and e^erimenting with different 
design strategies [FT] / ; 



An integrated framework is postulated, perndttii^^facii(B / 
utilization of database design techniques ; and tools . Its pjiilos- 
ophy is to employ several small 1 design topis, rather than medii^;^:::. 
or large- sized tools. 7 Thi&^Xeiids flexibility to tool use* arid 
'cbniBination, and wit£ : Wac± tool performing one well-defined 
sub task, overlapping of function is elifenated. In addition, 
database designers are' able to design, e^eriment vith,^ and use ; 
new tools of their own. The Databa's^ Designer Is Worjieiich encour- 
ages this by^ relieving the designers "of some of* the details 
involved in developing user interfaces, input/output of design 
parameters, -and, storage specifications. The graphic interface 
allows the designers to see the-viriou^^designs they are con- 
sidering for their fetabase £h£^ 

Since dfesighs "are easily modified; graphically, designers are 
encouraged to produce and consider more c^dW 

when the design group is progressing from one design phase to^the _ 
nextr.^nd i$. faced with a set of jpbssible designs to^Ichopse frbm,{ 
the system' s graphical nature pan-, significantly aid in th^ 
heuristics; of selection. L . V / ^ ^ 

- The Database Designer's Worl&en<± is b^ 
Database "Systems Research Group at . thfe University of Michigan v -" 
undfet ^cont^ct^frda the Uni^ ^ 
user's manual and the design ^specification^ are being completed. 
Future goals include having a minimal prototype running on MDLTICS; 
a more extensive and powerful version will be :in^^ 
Approaches to logical design for the DBTG model have bei^devel^ed 
and ai^em^nted^ previously in some Ph.D. dissertations at the * 
University of Michigan [Mlj IPX] . V L \ : 

5.3;3.2 The" Role of the Data Pi c^ 

• Workbench ■.. . J^:--^. . .- ^- 

The. group viewed the data dictionary system as playing an 
active^:^and\x:entral role in the database workbench architecture. 
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Conceptually, .it is the repository of the information needed by 
the workbench .tools. Moreover- it is the mechanism by which tools 
communicate with one another; Thus the DDS has -'as .one of its 
components ; a meta-database about the database being designed. 

We envision an expanded role --for the data dictionary system, 
as com pared with" commercially available products v In additi on tio 
providing lexicons of data item definition , data * typing *, and ■ m ; ■ 
synonyms , the dictionary, system, concept' should be/extended- to t 
provide the following services': * ' v . . v \ . _ . • 

*. " . - . Design Log . To effectively, document the decisions made 
at the various . design stages the: dictionary system 
must have a logging facility. This/ feature would 
record thi various ^options cohsidered.and state the/ 
reasons for particular decisions. ' * -V. • 

For example, user processing requirements on' an :. entity, 
set might dictate a subtype* partitioning of 'that ;set~. 
This fact should be recorded and be available for 
: -fp. future reference* should processing requirements change. 

* , Design " Aufcc Trail . The complexity of; database desigri* 
leads ' td' the decomposition of thfe design process, into v 
•\ .* manageable, phases, e.g.-, requirements analysis, enter- 
prise modeling^ modeling ^d view integra- 
tion, logical and physical structureVdesign, and perr 

* ■ .- f onnance tuning^ The. phases are linked, however by * 

the mappings that transform objects,. op^r&tionsV and 
* constraints from.one phase to the next. 

.The dictionary -system should provide an audit trail 
that records the mappings : used tQgeQier Wi$h Teley^t . . 
r * 'parameter valuers;. $fai£ information cbultf^ 

* r '~- characterize fr wbrkld^d" frbin level £6 levels -Sen- • 

. . sitivity analyses could be .performed to ' detenn£ne the. 

r seot&itivity of a : design to the parameters available to' 
: ; . .' the designer* "•: "-i "v'-' v ..:< <; 

A ^fe^udit^t^ail feat^e al§o allows high-level user 
. * ; \ ^eWsi to^be: related to the ;a^lic#^<mr ; processes: that - 
manij^ate^ also 
important, 1 namely, given a database object," what pro- 
cesses ^act oh it , ; from which: .user view(s) , and with ' 
what frequency. Information of this type -is crucial, , 
for view integration and for deter m i n ing ^ac.cessi path 
frequencies. \. \ . 



Inter- tool Communication . Workbench ttolp.must be able 
to* <x>mmiia i It'atfe with. one,. -another. For example, the jcon- 
straints specified in thie information 'model ^should ; j^e 




*' * made available; to; other: tools such as a form system for 
consistency checi^ datov application develop- 

ment aids wM^^ 
contr^ll^ ^ 

.""path fre^iencies/ etcf. £ \". * . ; ? V"" ; ' ;: v//^:^;C.;;-'^v:; r .. ; . 

.. * c . Metadata Management s The f eatbxes mentioned above show 
• ■ . ; ^^that the prime tim^ system . 

. / is tie management o£ m ' 

function is Addressed ^ 

5 . 3 . 3.3 : The Rol^ <tf Metadatk in the Data Dictionary System .. /../ 

One of the world's greatest database adminstrators recog- 
nized long ago vthe importance of metadata: "Itoowledge is of two 
kinds . We know */sub|ect ourselves Or ^ we faibw where ^e can^fd^d ' 
information upon ^it." - ■ / v - : - . / ' v ; > « 

5:3.3.3.1 j^^^s^jSL^^^^ . ' % ; * \ 

The advantages of having metadata accessible, to the user are 
almost self -evident:. V, In the first £lace, in an environment 
containing several independent and accessible databases, a user 
v ma^ silnpl^ want to know in which' database or file a given' lexical 
descriptor X$meatfkg$fe* " SitLce. 'pie- ijlterMl-desciiptbrs are / . - 
'often cocjed brhighly ^ abbre^tate^, :and since the user may ini- ; 
tially^use-a -term different ^ ; from ' tiat -used in defining the data- 
base, Textual 
comments *are also' important V 7 ', * ■ 

Metadata should also describe. structural ^ relationshijps and 
should-make them apparent to**he user. A query issued in a - 
high-level query language 'based on iTmiscorfceptioir- of structural; ^ 
relationships can often produce misleading results. Although - 
attempt^rare^oftenvm^ ^specially by "intelligent" query sys- 
tems, to represent the database i&.i ^ w^:1iat.^^.^^r /; s^es it, ;- .-• 
the extent to which a database sciema may be; ^ 
the user's view is limited, singly" because ^ 

models ,of the: designer and implementor may differ. For example, - 
;a relationship may' be one-many in the database; whiie tie user- 
thinks that it is one-one; there may be *np direct relationship 
betwe^ two, entities ;when the user t&inks r there is one . - 

Ap a Wr level, dajt^'folrm^ts^ re^rt-fbrnjat^ s^ pie, J , v 
characteristics of-, system interfaces , sltouifr alBfc -jbe ■ coteidered v- • 
i : as metada^ tod w^ 

> ■ transfer between paribus ' systems, t-y. ■ v : - ;-v ■ " '" ' 

O^amuef Johnson * (1775) , quoted in foswell* s^hnson . * 

- v-: ; v'* ■*'" > -' ^> t^a^Vv .1",'" ? /■ ' >*.'■.- ,- ' V- : - 



ERIC 



finally," metadata may £lso* be exploited :^.'o^^r^^^^y-\::: it 
High-level query systems andi natural language jsystem££bot^ 
metadata 'for itavigational purposes within a ; databa^ It is 
jasually the * fc case that this metadata must be manually constructed- f 
for these systems j >,simply because it is pjofefatt 
5trii5tural form "either within the database or 



5.3.3.3.2 Querying Metadata J. ; x ^ ' ' 

:': Many -interactive query systems allow, for gome' f prm .qf, < _ 
of metadata as well as of .data; For £ask of use it M ^ir^We 
that.' the * query * language .for metadata resemble the ^xegula? queiry ^ 4 ^"^ 
" language. However, for this to be>u ^some representation 

of the metadata must be found witKili the -data model?:^^ 
was felt that the existing commonly use*! data mode Is (relaticuial, 
•network, etc:) are not xich enough: to permit this and that a more v ^ 
sophisticated "semantic" model is required before metadatac;may be v 
concisely embedded within the database itself. ^ * , 



>V*V. 



The complexity of metadata depends on the pur^bse f or which 
it is used. For help in f ormulating queries , a ielattyely sogplfe - 
m6del is usually* sufficient ;that ^o^; ^e uset of the ternrin- \. 
ology of the database, some informal desddptip^ 
and ^ome- more formal description of *the reUtionships witha3f ^e7 
database (functional, many-many,,, etc v) . For the vp*jrpo§es -of ^ 
update and understanding integrity- constraints . somet^g-Btocfr <• *p 
"more sophisticated C^nd, as yet, poorly unde^ 



' ^ An, analogy wilfilprogramming environments " is appropriate^. - 
. here? ■ The support Systems . for conyeD^tional compiled gr ogramming 
languages seldom provide ak^ higher le^l/description of the f - - 
program, .data types subprograms^ etc., ;tiian.t^ 
Occasionally prpgifam libraries : are built up / andj some :0k^Jof ^ 
^dixlarity is enforc&i. fioweve^i these p^gr^nmang ;^|4^*m^.:^V 
generally held off-line in the accompanying do cummtaiiont ; The 
vfcetter interactive siys terns provide some : method by means p^ i^thl 
;;the programmer may . questions about "his environment:^ what : ^re^ 
tie names "of variables , what subroutines^ are available^^issq: ;V 
:Wr Examples are to be found in the programming en\aronmeiits v of ^ 
all the mbfe popular interactive languages* The same w211 -surely ; 
"^rbye true for databases^ to metada^>^ 

most:- in^ortance in an interactive environment.-" ' * ♦ i - V ^ 

- 5- 3.3.3.3 : Operations on Metadata \ 

!" fhis is one of 1 the mdst difficult problems ' associate with ;- 
i the use* of metadata. Should it be possible to operate npbh ^ ^ 
metadata in order to update it or to /produce new- metadata? Some 
useful techniques may be convenient^ described as operations ; *on 
metadata, e.g. , the generation of fa iiser view. Accbn^anying this 
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mapping there must : he an associated database : . 

access prijiti^ to ^ constructed, by bperat-; 

ing upoi metadatay the primitive operators should be well-defined, 
and some kind of calculus or -algebra should be ^ ayailable f or ; > v 
metadata operations. ; ; ^^^ 7 ' > . - V ;V*'; ; ;V 

. T& f operators needed to construct user views, are; those that ; 
^bse^^ijifo r i ^tio n^ 

l^s .well-understood) are operators? th^ 
ire a^umfcer of tecfmiq^ 

• formally presented, as operations on metadata • They include " 
constructing "superviews" [BM] : a view; that integrates data in 

"sey^l>lndep«nde^t ^ ^atabaf^es; the related problem of merging . 
databases; and the problem." of dynamically extending, the; ; schema of 
ah existing database to include new data. These are all problems L 
that Will require extensive research in database semantics for 

'their resolution. ^ * r • - • . <: ■< 

5.3. 3.4 Desirable Workbench Tools ./ " 

-■ w . : '!Ebe>jpc^'' > discuwd what tools the .workbench should have and 
tame % with the following>list. 

A. Information Models . ; V ; ^ ^ 

Existing, iirfom constructs , ■ ; ^ 

operations; and intrinsic^ cons to model both uiser 

and" global ^b'rmatiion schemas^ Although none of these models is 
machine-in^ time, we expect to see several opera- 

ti^naX^ th^ next "fw years. Needless ^o say, the information, 
model provides metadata tq. the data dietonary System, and is 
therefore' Qf utmost importance to ttiei workbench concept. . £he V 
model should have mechanisms to support both view integration and; 
process Specification. ..'.'V* 

BC Mapping Tools r . ; ^ . , "* .>, ^ Vv V^w ; ^ V 

Support r tobls are needed for the various mappings in the 
desig^prpcess;. ^ enterprise model (the result of requirements 
analysis) 'to Information model , ^infbrqiatipn model to access path 
schema and/inf ormation model to logical and physical- s^hemas. ; 

C* Constraint Subsystem < : : v v - ^ '■ 

The constraints defined in l3ie integirat^^ 
model can be implemented in four, ways: 

% ''.>m$ a J Sbme constraints are supported by the da^base implemen- 
tation structure (i.e., o^eTO^p-constraints are en- 
0 f orced-by in^i^m^r***^ hrj^rarchi^l^ . 



The remaining ^constraints may be stored; as assejftions",! 
for interpretation at query processing time [SK] ■ 



c. Assertions^may be automatically bound into access ? pro- 
. :;V^V^^ im ^."^ nx ^V : - ctfBipiiati^ bind:^external 

^schema s to the internal representation. Some experi- 
ments on- automatic. cpnstraint;.pr^^ have 
ybeen made^ but fio consistent theory? exists* V/ v-y'V' 

d. If no assertion Subsystem >is available^ tjieri the con-;* - 
straints should be included in .piroce^ : 
that V;are implicitly or illicitly "invoked by programs * 

■ using tSe database* ■" • ■V.v ■>.-■':/ 



D. Qttfery Optimization ' (an<f Cooperation) ; .-v * Vj ■* ' _ s } 

Knowledge stored in <the conceptual model can ^be profitably . 
;r used in the processing of qijieriess For example-: : JtezpodeTL^ : ... . 
should document ail enforced 1:N connections between r^ati^ 
that ; the -best join method can be chosen. The model must also * : 
document alternate paths; to the result, -so ^ / 
■ path's among logically equivalent paths can be /determined^ 

V E. < Application Program Development Aids / " - V - - 

'* ; 1 The knowledge embodied' in the' schema can,;: even without auto-^ >;■ 

mation , -reduce the effort substantially, during ^e designed , . 

• pi aiming phase for data ^gqilisition 1 f-or application programs. / 

f Turthermorei, if the^ constraints can : be used to automatically gea--^ 
erate modules which check! ian^^ 

■ t ions hips, update derived data, etc. , then ; coding effort is re- 
r duced. But more i^^ and©- v 

the relevance of its, contents will be greatly 6nhance^;V \ 'V \; : > 

5.3.V Database System ConmttnicatioH : -...j \ :W ^ * 

In this section we dear witi -the- problems associated, with 
^heterogeneous database system communication. -'The need for such ' 
conmiuklcation^ may arise for two reasons: : v ^ % < v ' 

(l) user 1 requirements for ownerships ^d control of information* . 2 r " 
may dictate a "distribution 1 ^^ differ- 1 

ent "data mbd^lW^fpr each application area, and possibly the use • \ 
different DBMS^tod;lwrdware configuratioiis, ^and' 

... (2) the systemsri^-Have been developed independently , are. •> ^ ■ 
op^xaticinal /.^d-^i^t^lie linked together ; because of^ the overall - ^ 
enterprise information needs -sy- > ^ . / ^ .V 



: 5.3.%I Organi zatiSnal Factors of M^ribiited Da tabases , > 

':, : ^ . ifli^r :^terp£tses move, inte < 
■ ; - ^apparent ^ conflictvarises^. The ^tralizedvcollecti^^^ 

tion^^Lmpiied by the Idat^base r^eclmplogy . iar often.seen as .the. ... 
• property ofwthe enterprise. This notion is with 
. orgaiilzational principles ^f^elegaUpa of ^espdns^ibilityvafid : 

authority. We aSsociate^wo^rshap ^^^^P^^^^^^J^ 
" the ability to act tut^eicessxve - ^entf alis^g^ 
* " and may sometimes fail to 'realize the fun^potential of informa-^ 
v ••' ;tiori or lead to ite; misuse .-, 3 ' ■ " v . ' .-. "/■'■ '•■ ' / ■ ';V ^' ] . : 

- Henle we expet^ ^ 
' tralizer the database 1 iogically. Often, ; bnt-not netessarilyy v 
physical distribution Jwili; follow . Management of corponate - ? . ■ : 
finances provides a simile: ^a" single corporate account «r multi- . 
. "• pie divisional accounts may provide the storage ^f^cf edit^ but . 

• individual Ikuu^p^^h^^u^x own budgets and plans for revenue 

V ' and "expense. JThese 'budgets ^aM^^f^^J^^^^'-^ .^-'/^ '" 
*• application. schemas obtained from; tie ^diviaual users . If the 
enterprise management delegates operational' authority and xespoh:- 
sibility to one of its members; then that ^ member* should have the • 
corresponding data authority, and responsibility.. -/ V * *.? • 

.. *. * "' ■ - . «. - . •"'rv • . • 

Data ownership is the term used to' describe a user rela- 
tionship to the data for which responsibilil^ bisjheeif assumed- - 
and "authority has been granted.,: If , for 'example, a" bank branch 
manager is responsible for the bankrs customers, in the 'local v . 

• area, then maintenance of the customer lists, their addresses, . 

. and the linkage. -to various accountsvis the respons^ili^ of this 
manager. The -integrated schema may impose >orc constra^sj for 
instance a "Customer with a non-zero balance : may -not be deleted* 
»" but the schema must also support all actions that axe^authorazed,; ' 
such as the entry of a new customer. The integrated schema . 
provides the crucial , information ueeded- to; cobrdi^te ^ activx- ^. 
ties of the local- schemas . -Data ownership. is noted. in the rnf<?r- 
mation model; All data described must; eit^ be^bwned^or be 
geaexatable from other data through the 'use >f :pome con#utational. 
procedure. These procedures .are attached to ^^i^or^t^-^ 
model. . ■ '. *. : -<. •#> . ; ;- ' ', 

^ At times" the read frequency at otherf sites in a distributed - 

*svs3tem may be' so ^togh? that; performance deSands that locally owned 
' data'be istored at the *read site. The dati may; then either be ' >r' 
k ' kept ux^quely remote, or be replicated. * If -the .Wi* ' " 
^cated one -site: remains r the primary copy site and: isr xdentifi.ed as^ 
- such: If updates have to bccur; at Sore 'Jto one "site, then-more ^ 
" complicated mechanisms axe required,- The notion of a true-copy 
token [M] - which-identifies the^ primary versiM inay -be used.te 
' r- contxbl such databases. ^The truercbpy token- resides" where^ the 
*; ' update priyilege resides, and iff moved as needed. Before it xs \ 
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moved inter-site coraisteicy i^tetablishedt Tte^w the 
true-copy token may -on^emand : or on schedule • ; v An example of a 
scheduled movement of a primary ^copy is seaa iJi vthe branch J)ank, 
where local accounts are maintained in the dajrtime, but central 
postings from other banks take place at:night; t^ 

5.3.4.2 < Technological Factors In^umcinfc Distributed Databases ■ 

^in-some-^fctaiz^ 



nology was questionable when it -was found that expansion of 
existing functions, or integration of distinct ^plications has : 
cost greater than expected, often greater than the c°s£ of the; ^ 
original applications / ^ looked* . 

'Upon as a remedy to data processing ills - . does not. guarantee the 
required growth flexibility [GAO] .' Many database systems even ■ ■•: 
have a. hard time living up to their existing specifications ,• ' 
since- they are typically based on software 6f -the late sixties- or£ 
early seventies. 



Distribution may involve distinct computers , but included r . ^ 
also distinct databases on a single machine. The logical prob* . 
lems are the same ^ although 1 lower communication bandwidth to 
remote machines can make poor situations truly intolerable. 

\ In order to plan appropriately for a logical integration of r : 
diverse applications and databases a substantial modeling efforts 
may be required. Models, using consistent and formalizable 
notions , have to be established and rverif ied for all, significant 
existing tasks, using actual documentation or programmer knowl-^ >i 
edge, iyfiigh-level sketch, with unverified assumptions about 
actual Operating processes , can. only be misleading. In addition,^ 
models ipay be constructed "for new intended applications. : : « * 

An important result of the integration process/ is the knowlr > 
edge that is collected* about the data resources of the , enter- ^ , / 
prise." Even if a database is iiot in^lemen^ 

effort, the. model provides managers, system .analysts* and, program- 
mers with information about existence ownership ^ ; sdope,^nd 
constraints of the data* If a continuing maintenance ^ ef fort i%^ v 
made, then the timeliness r and . quality of* the 'i^sti^^^^ maj^'''^ 
also be documented. * ? . - ^ 

• - .. ,.. • v . : • — - : . ; ■' ^ ■■.^^ . 

Operations integration will be more difficult. Only a feW. c - 
systems today manage distributed data. While algorithms for mart-r 
agement of replicated data are .well understood [ GM] they 4o not 
appear dn; generalized systems . In many cases explicit bridges 
may have to be built by programming staff to share data among * 
distinct users. These bridges may be specific,' dften^movixig.- 
files created for that purpose between systems. As alllernal^v^^ 
we see_: 1) automatic query' processing throughout 
{database" (most methods discussed assume a global schema^r; 
access through distributed transactions, and 3) sharing o^^il^^ 
by copying between nodes. ■ , :i&X' -.1 ^£$(P^Z& 




' .The^d criti ?? 1 f o£ ?°? d : ' r 

response and consistency. ? ICnbwn ^iuery types are deqpnposed into. V . 
- component transaction sections ,> eaten transaction,; section is . ; i. 

placed 'with the database it needs , some sections invoke and : 
; correlate information from tie other sections; Careful planning . • 
--^an^mjnimize problems of interference [BSR] . If consistent models- 
" : iare available inVstbred f bm on • the parttcipatin*; databases ^ then^* 
'••« Yremote queries ^can be phrased 1 in terms of these' queries -and in a . - 
/ truly distributed fashion. — . . " -A ... jr ' » ,:: ;j"..-;*;' ; 

• The Validity of •■ Pis tributiom : ? v.. 

' Many existing non-shared" data are unintentionally distri- 
: *4-£-'\ buted. The fact that, existing datioas^lAi^^^trj^i^d^di^^^: 
. i • • in most cases that tie cbmmunicatiojfcba^ were- '. 

' indeed limited. • Incremental*' integration is hence quite feasible.. . 
For instance, much- of the data sneeded for the operation of a 
warehouse is used only locally./ Information about shipments does 
not need to flow much faster than the shipments, do. A small 
percentage of queries result in out-of -stock conditions and 
should be rapidly distributed over adjoining nodes. Management 
, information Jo£ -periodic distribution is best summarized locally, 
'fusing. ^'gjobaia^stablished procedures , and^can be transmitted' at - . .'v 
■ •• ' : low priority'.:; ' ■ . • '. * • " 

h Increased'-automation of operations, such as seen in modern 

•. warehouses , requires powerful and reliable Io.cal processing 
^ - capabilities . local' systems may have multiple workstations . The 

"* * demands on availability, control, and^anawidth make local, stor- 
age essential. Many of these distributed systems will be rela- 
tively small; This will reduce some of -t£e complexity now needed 
-in database management systems designed to deal with extremely 
. -farge files. Even though distributed systems will provide less, 
•;J J;', shariq&^p^oim^utiiig power and less aggregate •hardware oitiliza-; 
' tion, t^eMe -iTs a 'positive compensating factor due to the smaller. , 
scale Alterations.. .In.numerical terms for operations on:; data- 
bases t|&*|ieed sprtingSn some fosm, the n log -n performance < 
bound ig^i'ess -for-m distributed- systems holding n entities each ^ u 
(m(n Tog n)) than for a. central system of equal size ((nm^ log 
- (mn)): ; '; . ' ' [\/. ' / . 7l -V ; '£ ..r-.-rV" " ' V"" 

When systems become small they may need to depend to a 
greater extent on remote facilities for maintenance, logging, and 
recbveryl Issues of communication failure and processor failure 
need detailed analysis . If data is replicated, on f oreign nodes , . : 
then some backup can be provided from those nodes . . ; _ • 
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• : -> 5.3 .4. 3, the Data Restructuring and Conversion Approach to v 
Database Communication' ^ p ' ^ ^ 

; Normally, a' distributed database system ii^^iwe^ 
distribution of databases and database management function; across 
\ multiple, tightly coupled nodes in a;' communications network. All 
nodes understand a common schema arid a homogeneous, set of com- 
mands as Well as their related protocols v -"r: . ^^v^i^i- 'VAl-: --""-^n "■" «. " ; 

/J \ r In the realistic future, however, distributed data, process- 
ing will be required among loosely coupled nodes that will commu- 

.'■ . nicate asynchronously. Furthermore, different nodes may'use.dif- 
:" ferent DBMSs. To operate effectively in such an environment, 
three inqportant facilities are required: ; a)/ a data dictionary 
system, b) a general "data ^translation facility, and c) a store .-. 
and forward communications service . \ ; \ ^ .- v 

IBM 1 s data extraction, processing, and ixestjuctnring system v 
v -(XPRS)f [IBM1] is one example of a general data translation fa cil- 
•ity. n XPRS implements the* DEFINE da ta definition language, and v 
t$ie± CONVERT data restructuring language . Using data translation 
techniques, users -can extract data from. a source, database .and map 
it to a target database. . The store and forward facility transrr 
ports not only the data, but also the data translation program ~ 
. (e.g. , DEFINE and CONVERT^ respectively) that together provide a 
. "data translation schema" of the data; The data dictionary ^playcf 
the important role of relating the data translation schema, to the 

- database schema for the^iven source and target -database manage- » 
ment systems. In effec€; the data translation and data diction- 
ary facilities can serve as a "bridge" between heterogeneous 

- DBMS' s. - • ; ' V • < y 

There are many scen^pios £ or distributing the data mapping- 
process. For example, files could be extracted from the source 
database, restructured in the sqiflrce system ^and then sent to the 
target system. Alternatively, if /the data translation system * 
^ resided in the target: system, the unstructured source data could 

- T>e sent (along with their definitions) to the target system %or 
restructuring aridjvinsertion into the target database. 

! '■ . , :.V ". ' ' - . - ■ . ....... . . 

5.3.4.4 The Federated Approach to Database Communication v 

One of the moist significant trends and important challenges - 
of the next decade in the area of computerized database systems 
is an effective supportjPof decentralized collections of data. > 
Recent work on distributed databases has >f poised on techniques to 
store and access data. at various nodes in a computer network, as 
*. if that data were part of a single logical database; these efforts 
therefore concern the physical distribution of data. Signifi- 
cantly, logical decentralization is an equally important concern, 
and the current' approaches to logical database decentralization 



rinadequate. In response ;£o "the needs described above , a new 

iaba&e- system (software)" architectore 

termed fedex»£ed datM^ 

[ffi, J^?] i^the. ligit^d^^ 
•;' •partial • integration • \ ;; 

" A federate^ datab£^ 
ents, each haying its £wn user- level structural specification v ' 

~^~coi^ 

related but independent, ^ ^d the 
* Topically, a . component, cbrrespbhds to a • cpUectidiirof dita ^needed 
by a particular user or a^li cation, or ar co^ctiott 
related applications. The ^components in a^ federation -are 
together by one or more federal schemas that d^cr^^ the (data 
that is to~be shared\by 1±Le varioi^^ed^a^ 

* federation notion can\be applie^Crecursively.) The federal ; 

V controller is a. database system functional module that supports* 
communication and translation of daita aro^^ 

federation, based on. the federal scihema(s); l ' ] ^ ' . 

At present, a database federation tool is be^g desigped 
[MH], and a prototype will be ifflplcanented. This prototype tool, 
will provide facilities to ^ 

(component schemas); the tool will, interact jrit3i ' a .^esigner and - 
accept a set. of vschemas that are ; ;to be* merged^into a federation. 

An important use of the prototype federated database^ system . 
development aid described above is in establishing cpnteolled^ ^ 
sharing among existing databases . To accomplish this; a semantic- 
schema is defined for jgach component database , .and the tool is 
then used to define-a, federal schema based on i&ese component 
schemas. A prototype 'federal controller, an integral^ part of the 
development aid, will automatically support data conmunication >, 
and translation among the components , via tie federal schema. 

The last step in -logically connecting the component data- 
bases is to develop a mapping from the actual database strufcture 
of each component to its corresponding ^ 'iseni^tic schema; this can 
either be done on a case-by-case basxsV or 
classes of general-purpose database systems^ can be* developed 
(e.g., to a relational database mana 

DBTGi etc.). . . '.'C^'S- ■ ' 1 "■ 'S * * 

The federation concept has a much wider applicability than 
merely a method of supporting logical database decentralisation: 
the technique of federating information is a form of abstraction ; 
that' can be used for structuring both data and programs . When 
used as an abstraction technique, federation facilitates ^econ- 
structitta of complex collections of data from simple collections 
of data, and the 4 construction of complex program modules from 
simple modules . That xs , data and program components can be y 
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'combined into ~a federation. Moreover, the technique of feder- 
ation abstraction; can be applied recursively ta : form hierarchies 
v and -other complexes of data and: programs ^ ^^^^^ ^ ; ■ " 

5.4 jjaggj^ 

In the following sections , relationships between logical and 
physical database design are identified. Some resjilts of logical 
design^^which -influence physical design -decisions , -are- reviewed 
and the impact of physical design decisions on logical database 
design is examined, " ■ 'v£v*r. : ^>,-; : -.-:' 

5.4. 1. Results of Logical Database Design ^ v : 

Physical database, design is based on some of ; the . results of • 
logical database design. Such* results provide information abotit 
entities and their attributes , relationships Between entities^ 
and descriptions of operations that are to be performed^ . 

For example , information about 'r entities; may include : 

' : . ' ' ' : - : P • V :■ ~ ' . : 

* occurrence -volume^^mime growth rate 

* keys (4.dentifiefsi>^ . * 

* privacy. -and security constraints: ^ / # ' 

For attributes of entities : . v ; : 

* storage requirements •?.:> , \" • 

* integrity, privacy, and ^security , constraints 

* number of distinct* valbes, volume growth rate 

For* relationships between entities: ^ ' 

. -owner ,' member entities . • 

* number of member records per . owner record, volume 
* growth rate ' . . <■;.■ 

- . V- \ ■ 

For operations on entities and^ relationships : / 

• • r * 

* type of operation (retrieval^ insertion, deletion, 
etc.) ' , - /' .>•• ' , 

* frequency of operation, frequency growth rate 

. * operation selection criteria, output attributes (if * - 
• applicable) 

■'*.'" "vojLume of records affected by ^operation, volume; growth 
rate . _ ; ■ \ "" ! - \- > ■ ■ 

These lists are further expanded and are discussed in more detail 
in the sections on physical databases. 
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In principle logical- design is accomplished without regard . ; 
to performance,, while physical design alternatives are r transpar-~ 
ent ta users.' In practice., however, transparency of physical/ > 
design decisions is not always possible as the f ollowyig sections^ 
show. >vL' ' : y-.-'^.y-J. " ;•..,•/ •^•^i-^^:. • "'c :T"Y-"V 



5.4.2 ^erlap -of ' Logickl and Physical Design 

Logical -*and physical database-desfgn f or_commer:cral. 



DBMSs 



•are not > independent-processes To indicate their overlap , con-; 
sider the simplified database design process- of Figure 5-1 which 
consists of four phases. Logical desi^i is identified with tie 
first three phases; physical design^ is "identified Iwith^ 
fewo: The oyerlap. occurs during the. phase of Schema Design (SD, 
see Section»?5 . 1.) . ' 




'%' ■ The database schema in k specific data model/identifies.cpm- _ 
^ponenta of a database using the available schema, constructs in 0 ' 
"that model. Typically these constructs are record types and . ■ ■ 
relationships among record types. The next phase .of realization ; 
of a schema supplies implementation details to the. schema so 
outlined. Such details include specifying^ entry points or «?CALC" 
records, file structures iofoiised,- and whether or not parent 
pointers should be used <&n rel^tiouship "implementations . f The 
selection of specific mettiodsiOf l^iementatioh is based-on an . 
. analysis of logical- access ^ai^; During the final-i> 

database design the schema specification is used together. with 
the knowledge of. the transactions agaxnst:;the schema to perform a 
"schema evaluations An assessment of database performance: is; done.: 
to arriyeat a proper assignment of physical alternatives'. ^ . ; ^ 

* Database design is an iterative process . ' Refinements to a . ■ 
schema are made, for example, by altering implementation details 
and reevaluating the schema; Those schemas whose performance is 
j udged acceptable are candidates for actual implementation. -This 
refining process is indicated by the arc at the bottom in Fig- 
ure 5-1. The loop formed is often identified with physical . ,c 
database optimization . * .OV.tJ >r 

Because commercial DBMS schemas are so closely related; 
physical database implementation,^;^ *$j?K9 T ' 

\?. relationship implementations causes Schema designs to, be -alteredi 

"In Figure 5-1 the dotted arc from Schema Evaluation -to DBMS 
. Schema and to Global Infoemation Model indicates restructuring 
which may sometimes be attributed to the overlap of logical and 
physical design. * Examples of this overlap are presented in the 
following section. 
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' 5 . 4:3?-* Alterations Ojgf I«6gical Schiemas for Phys ical Rea&pns • 

Although commercial DBMSs^sirpport ^ a varietur iof methods for 
inplementing' files and linkages between files, not all fundamfen- 
tal methods are . supported • - By* altering s chema; des i gns , such ^ 
omissions are circumvented . ;.■ %r<.. •••^^•v: : ^A vSi^ 5:'^: - o 

Consider the situation where record partitioning is not; 
j supporte d U Record jarCitionirig ^alsa: known^ as seg^Dentation ^ 



•involves the partitioning of a record type by attrihutes^ to form/* 
>two or more subrecprd types /* Record 'partitioning m^ 
perf ormance reas^dis- (e . g, , s^arktihg. "hi ghly ; referenced attri- , 
T>utes from- those that are iaielj referenced) 'or, for Security V 
reasons^ ffe.&J, separating confidential informs 

/informations . Record partitioning is achieved in cbmnercial : ^ 
DBMSs J>y defining each subrecord type and interconnecting them by 
1:1 relationships in a .schema; figure. 5-3. shows the partitioning 
of an .^employee record type into primary *;<&nd' secon^ity, subredord 
typeS... Note that in addition to ^the alterations of -a schema , A 
application programmers must supply, routines '.'tlMt\ : aih t ne^ssa^ '■' 
to support operations on partitioned, records i ~ \ : ^ ' 

." Another example concerns file partitioning (i.e. , .the.par- 
titioning of a" file into, two or more subfiles) 7= Like^M 

^partitioning, file partitioning is used for performance reasons ■ . 
(e.g., separating highly referenced, records from those that ate j r 
infrequently .ref efenced)^ % or for .security treasons (e . g. , - separate 
ing: confidential record^ from public records). * File partitioning- 
is achieved by defining, ^record type for each subfile in a 

^schema (Fig. . 5-4). /' 

Some DBMSs ; do not support secondary indices. ' jjn such cases, 
an index for an attribute can be implemented by a record type, 
"where each record of the type contains ..a distinct value : that ' is 
assumed by that attribute."* Each record is then linked to those 

/data records that possess that attribute value. Figure 5-5 shows 
an inversion of the^Depaftmerit attribute of an Employee record 

. type which is based on this construction. In a similar manner 
additional record types,, .which serve as indices to other "index" 
record t3^pfes, can be- used to construct multilevel/indices. Thus, , 
schema outlines are alteredueach time an index .is created or 
removed. - v : " : - v 

Occasionally, DBMSs cannot handle large or variable rlength 
data rWcords.. To circumvent this problem, "data Yecprds are 
expressed as a sequence of fixed length records .» The first 
record of a sequence is the main record and the remaining are 
trailer records. The/main xecords. define a main record type and 
' the trailer r^ords define a trailer reicord type!?* The records of 
a sequence, are^associated by having- the main record;be the owner 
record ^d/;t|L6;.trailer records as member records bi a>-relation- ■ * 
ship occuxrdicp; JyEig.. 5-6) . ' ; ' 
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Figure 5-3. An Example of Record Partitioning 
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Figure 5-4. An Example of /File ^ Partitioning 



DEPARTMENT 
(INDEX) , 



EMPLOYEE 



works-jn 

EMPLOYEE 



before construction ; . ^ V - after construction 

' . V Pigure. 5^: An Example of Secondary Index Construction 



ERIC 



-122- 



143 



instead of: 
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schema has : 
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TRAILER 
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Figure 5-6. An Exampleof Handling Large Records £ 
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Figure 5-7. An Example of Redundant Relationships 
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■ A fibal erainpie Concerns the ijEplemei^ 
shipsf* Relati^teps ^ 

pointer arrays arid 'ting l£&t$i or by procedures^ sjuch as joint V 
: operations. Ifeing both metiho^s allows almost all useful relation- 
ships to be defined in a^ siciu^ ^outline • Only ^os^ relation-: 
ships that are df'priiiia^ database 1 processing need 

be inplemented l>y ^ not currently impor- 

tant colild^be ii^lemen^ Unfortunately, rnp^t ; / 

DBMSs. suj^ort only strudtiirJai- oi^lementations^ and TOj^equehtly, 
alt^^tionS;^ to schema s may x>ccur> ; r xV p ^ " % ^ 

Consider the case of Figure 5-7 where the relationship 
between record types A and C is . redundant. That is , A-C can be 
deduced fronTthe A-B and B-C; relktibnshipis. ~ For /performance ■> > 
reasons, A-C might be ^in^iemtoted :i involves 
records of type A.and C, but not : B. In commercial ; systems , -if 
A-C is implemented, then A-C is present in tie sdhema. If it is r 
not i mpl emented + 4Jien it is ■ absent from the schema, r: 

* The overlap. of logical and -physical database design is due 
primarily to the absence in commercial DBMSs of some fundamental y 
methods of physical database implementation. If such fundamental 
alternatives (e.g. record or file parti tioning) ^^vail^Me, ; 
the design process ca£ be greatly ^levia ted ^: Anot^r re^sbh. i^. r ; ? 
./-tha€;iiii0st : ']H}Ls used by the DBMSs to define schemas contain logi^ 
cal as well as physical constructs. Until DBMS DDLs are devel^-> 
ed allowing a clear separation among the two types of . design' . jv - 
decisions, the logical/physical desi^ c^rlapr.is = 1^ 
continue . Future DBMS^should strive to achieve the ideal of * \'y r 
all6wing; ; ^e' iesi^er a : cleiar choice among physicajVdesign air 
ternativ^s wltfch must be* explicitly recorded ;^nd subject to 
modification^far tuning purposes. : , ^ ' f - 

5 .5 " THE ROEE'oF DATA DICTIONARY SYSTEMS IN MANAGEMENT OF DATA 

5.5.1 Introduction :>■""/*' ,:\ f vV : ' 

:';Tbi& section is a result of the discussions held by Gyqup 1 IV, 
which took a : broader viewpoint with respect to- the management of 
data and database design in a global organizational framework. 
-They concentrated on the role data dictionary systems^ should play 
to facilitate data management* ^ 

Data is playing an increasingly significant role as our 
ability' to technically exploit it is expanding through the use of , 
computers and related technologic This role increased even 

more because of the g^wing^ d^ndenc^ , of organizations and 
managers^oh inf option systieins for pfe^riia^ 
tions. today's managers are not only willing to use.^ 
jputery but expect to use it, and will be in a position vt£ iiisist 
woii access to. data to aid them in their jobs. ' 1; V:/' 



\ Thisipattei^is ;i 

1* Use of data ly^Iii^ 

decision making will increase substantially . j , J,-*. 

2. End users. will i^reisiigly retn directly^ 
*Y/* obviating^the neei/foi^iproiraniiing by aa MIS department. 
v:V^<> ' *- : " < .- \ ■ :>' - v * r - : ' v > ..' • ^; 

^' -A prudefct person would expect tias demand and/ p ^ 
iti; : Pr^aration^ requires iacreased^e^hasis' on } * 

management^of data r be coming a vitkl mission . In order to prepare > 
for tie anticipated rapid- growth ^ in DP, ^ a^d for the increased^ use 
of data by end users, the^-time has atriyed to r address areas 
concerning overall management of data (in addition to the technical 
.support of "the DBMS itself) C • ^ ^ ; i % 



'In, ..the past many^prgs^^tibns brought i^ Sj DBMS and then 
' ^focuse^on the tpctfsjr/stiandards, etc., needed t6^©ake the DBMS 
;wbrk^ " This f req&jitl^resixlted 1) the data dictionary.^ ^ 

• system being considered subordinate; to tb&ipjj^^ 

tions losing sight of $fte; x>bj ective ibriigiig in the DBMS ^ 
. 3) the DBMS being used as ; an extension to file management systems 1 

access methods. * ~~ £ '.■ 

. >. What should haveV iwj^ened? The focus should have been (and 
still should be) on '7lii%.?e£ult' ? tb be accomplished with a DBMS; 
that is, in^roved.profi^ttor reduted expenses.). % ^ "This may 
result from improved efficiencies or from better decisions through 
improved or more ^timely information." [Go] These, in turn, may be 
accomplished by ^ in^roying. data usability by^jnanagfhg data as a 
resource. Under thxs approach, emphasis isVi>^ % - 

necessary to manage the data: the DBMS and -the Data Dictionary 
System. The DDS is no longer t subordinatfe ta tiie DBMS. The DDS 
can and should be enhanced to provide for management of data . ■ • 

First , what is meant "by managing data as a resource? In 
general, it means increasing data usability through pl annin g, 
organizing, directing; and controlling the data. Data management 
should make available a comiiunity , of data to a community of , : : ;\'-V:u\- 
users, across organizations; across functions,' and sterols loCa-y ^ 
tibns for people at all levels to aid them 'in perf owning t^irv^ 
respective jbbs.v • :>■-./ "->• . I" & ";' 4 . '1' 

Usable data is findable,. unde rs tandafcle, avail^li, prgai^-^> 
.zed, documented^ maii^inable", accuratpi timely , private , : and .• 
" seoire ^ v . ' ; p .'. '=•. :y M:, ... 

Data has the same characteristics 6t m cost, value, and scair- 
»city as/the more familiar material,- iiirancial, ^ 
£N]. Data is the raw material from*wl£&-to 



Similar to other res<>urtes, data must also be managed. As indi- 
cated by Bakke [Bak] ,.' activities necessary; to > manage resources in 
'geaera^ ?■■■:'•< *v.v' . v*.V. 

IV- tWDERSXA^ thdrbugjiy its natare^ " 

^ t ions', composition 4 ; s6urces,^a^ ^ v . 

■■;"--"2. MAINTAIN and conserve the resource - acquire / maintain, 
t .'■*'" and . conserve quM of; the reispurce- ; 

n eeded by the organization . " J 



v* ; 3; EXPLOIT and employ the resource ^develop and exploit : V . 
: ^"JfcKe potential of the reso^ 
. ; ^ . effi<n.^t"4pplication to t^e activities of the brgani- 
j.^c' ■ zation. . ''/<-■ * ' \'\ . . 

■■ r ' ,r /' : " ' ' f"" : -;?y :V . /, ' - . V;-. "o ■" -. .,:.k . ■ ' 

; »:>■.' A- INTEGRATE ttfe resource - effectively integrate its use 
with the use of other "resources to efficiently bring 
^ about a desired results . V^- ^ . ' 

, 5 5.2 Approach ' ^p? . ' 

w v;-> The group approach^; the problem of determining the role of 
^the data dictionary system by examining several specific areas of • 
Cusage that may requiicrDDS support. ^ These areas included datoba^ 
• design, distributed data, business* systems plamiiiigi decision 
support systems, office automation, auditiiigj database adminis- 
tration, manual .data handling, and t|ie management of the metadata. 

j -Th* following .section contains a synthesis of the ideas ' 
brought up by examining the separate usage .areas, /but the rep^)ii: 
is not bounded by considering bHly traditional database applica- ^ 
tiohs. Rather, the rble of the data dictionary system .is...^; *q$ 
approached by establishing what the DBS is and whit it shoiilid be . . : 
The group's primary focus .was on computerized .data-;procesS;iiig 
systems, so, little was done to explicitly include, nonr^utcpated : r 
data; however* the group attempted to "avoid recommendations that 
explicitly, or by implication, excluded iib^ 



5 >5> 3 Summary of the Recommendations > \ 

Though diverse applications were considered*' it was' decided 
that it, is possible and desirable to have i inde- ... 

pendent data dictionary system to si^port 'i^e information manage- 
ment environment. The group views a DDS to be a central component 
of inf ormation" management. With^regard to the overall management 
of an organization * s information, neither the DDS Mr the DBMS 
should be considered subordinate. Rather, the DBMS and the DDS 
should be regarded as allied tools which are vital and virtually 
ins eparable in accomplishinig the common objective' of managing the 
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inf onnation iesour ce . \ JxsxXh^^ 
/one pxijfadea specific ^^tionsj^ 

functionality, that nee<^^ ^ v- 
and ihe WS^ " 
systems, but is vi&l--4tfr manage data and make ; it$teally usable. 

• :. • . . - ■■■■ c . t';;Kv.'i^ * '-v -. • 

V ' fhere are jnany types j^^t^- may reside 

either ii ttip data dictionary or in a database ^controlled by .the 
database manager . Regardless of its^iocatt6n, ^data about data- .< 

• bases must be locatable through -the. I©S, ^ 
system must ; associate the data about ' databases" Mother' metadata 

: in ^e-enyi^oini^ t^ : r~ —■ . ; fry . - , : 7 ,^y ; ',' .-' 77 ' y 

A major* group decision concerning the importance of ^data ^ 
semantics led the group to include data semantics : ^A' : the dat^Bi 
dictionary system. Descriptions of the semantics of an organiza- 
tion ' s data are to exist in a form that is meiand^ user 
and a form that is. isable by* the database manager^ a$ well^ 

The r , following outline summarizes the dictionary contents ^recom- • 
mended by the group : : \ •* *' '* 



I. . Administrative JM&"£a,tlie Dicti^p^y 



.... ^ - A* " Inf opnation ^esourcfe ttw^^anent Data -. , — 

B. Descriptive "Admini^^^ 

C. Processing AdministratiohvData V'""" A ; 
II. Semantic Data in the Dictionary \K 

- ...■'ill*- Processing Data' in the Dictionary f 

-V~ Th^ advocated data dictionary syst»^contains current^.l)DS 
capabilities as" a subset, but it is general enough to :$"ppi>rt 
fetuieldatabafs^ systems where, for exajnple, data semantics are. 
:tocbi^^ database or the dictionary. L ' ; 

'X^v; V - " * . : : "" ; -..""^^ ;" ■;■ ' " 'f - : ' > .'■ £\ 

j jte fining The DaterDictionary ' System : . 7 - 

T^r > . Defining information management as a special instance of 
resource management , which requires understanding, maintenance , 
exploitation and integration of the resourcey delimits the role 
•■bf . the" dictionary system as being a primary and fundamental 
^Component of the overall data; management function; and, does: not 
^tototra^ . or categorize, the data management activities supported 
Vby tte " DDS . , > • - . . • • \ 

% As resource manager, a data dictionary system is" * 

m^H^i^iS da£Wy>: whSre <Iata 'management includes the pla nnin g, 



control^ direction, and organization of dat^. 5* 3^ 
"■' ca P ^ e divided into tiree : ^ admiiixs-. -ll 

■ ' % ; " - txation; process^ag- and senantics; ^ 7,1" M: • ^ : v . : ; . 7" ; ' : 7 

In essence, -the DDS ^ ^ ^ 

"J, data dictionary system is defined as ft int&gratj^ at\ : is£a J'Xv- 

primary component o# the information management* system itself 

' dictionary system as a data ^ management, tool that^ is separate from 7 :. 
(and subsidiary to) the. database management system. : Being an 7: - 
integral part of the -database manag^e^ ^ 
— ^jhe^BBS .is t hfe^bo otst r ap ^-d a t abajse around^which aH other data* 
"7?baseis "can b£' organized. " f ; S;V ; ; ^ <s 

. • ■ . : /77^- : %^ : 7 • - " i ^/ • , ' ', . ■ ■ 

v " • The remainder K 6f this report concentrates on explaining tie ^ ^ 
"areas of functionality" of, the metadata^ The functionality 
discussed below is "not put forth as a complete definition, but is 
• suggested as a good starting point for further investigation^ 

' ■•■ • .. .' ' 7^ .. . '[ \ 7 ...V-V • 

■'• 5.5.3.1'. Administrative Dat# -in the Dictionary ' ^ 7 

In the data dictionary, administrative data is data for tihe 
proper management of resources* The rescfurces are either in the ^ 

. environment, or the resources are des-prlptions of administrative 
data, o'r -processes bid: a'dministratiye data which are tlie dictionary* s 

... own data . These [three groups of data are outlined below: ■ ... 

- ' " '. -7r>' ^ ■ : ' ■ 

\C - A< > Inf omation^R^ou^ 

.7. 1. Basic item, description " > ^ 

;7\ 2 , . 'Names** including synonyms , homonyms./ and 

** related names - 

"~ 3. Regulator(s) , source (s) , and sink Cs) of the 

7 . item .; , . ; " 7" 7;- 

-•.•A.- Business needs; . "\ 7. 7 .7 v. 

: 7 5 . 7 User needs v . .. ' • 

6. Usage and: frequency. descriptiofQs'' 7 , 7 

7. 7, Security constraints ' 7'*"'77"- 
7-7 7. 8. Synchronization data 

7 * 9. Integrity, data ■ 7 7 V ; 

"7 / 10. /Recovery and resynchronization data 

11- Audit trail . ' 

B.' Descriptive Administration Data 

1>7. ^Editi^ and : Presentation formats. 
7" i2m " Encryption and "'report generation needs 
* v 3. Geographic location 

C7 Processing Administration Data . 




1. v* Security. 
2; • Integrity > 



• - • - : . ; ■ • ■ . : 7. :< - ; ; ^ -7^ x . 
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The following paragraphs explain the above components: y 

Information Resource 
necessary to manage not only the data but: also the data manage- 
ment agent for. the data and the user^of the data. The data 
management agent may be an' autpmated^DBMS or an individual suds 
las lit dlerk or -secretary t In "either ; jcase , the Infi>rnaktion Resource 
Management data provides^, a global context i^thin which the user 
or data management agent; can understand the^ data item*. The 

^Descriptive Administration* and Processing Administration data are 
the data dictionary's own description ^of what it contains \i , these , 

^w^rections^escribe^ 

data contained elsewhere dn( the* dictionary : :(the; jiftscr^X^ni^d. 
processing facets of the dictionary system are described : in the 
next tyo sections). . ' \* J ■•■ 

The following is a brief ^explanation ;of each piece of ifdmin-. 
istrative data-in the. data dictionary* ; .-..'*:';.■ / , 

A.l The basic item description is a natural language ■ explana-; 

"} tion of; what the item is, and its relevance to various 
; applications, users and functions of the enterprise. V 

. i - : . .'• ■ " '. '/ ' . ' 

A. 2 The naflfefe are those by; which the item is known, >s well as 
any name by which the! item should^not be /knoWni. ; 

A. 3 The regulators , sourcfes , and> sMks of "the data item incl; 
the person, division, system^ etc . th^ Regulates the dal 
* item; the ^sources from which the data item is or can be 
M received; "and ; the sinks to which the data* iieim is or can be 
directed.)- ^ 1 ; v "'/' ... .'■ > : : ■;T-.'.«V. • V/' 

A. 4 The business - needs documeot whff ^the data was originally. ~ 
created and the purposes idiat it crirrently serves within tjjhe : 
-'enterprise*. -""V. * ' ' •:• 

. ^ ' " -. ' /.'V- ■ .' ' v'. .-';V : • •■. 

A. 5 Thfr user needs include user imposed constraints necessirjg: . 
for the data to be useful. Examples include the data item ; 
being absolutely current, or having been stable for at -least 
a month, etc. - • - r " 

A. 6 The usage and frequency descriptions provide information 

such as: "item must be processed daily", "use only after run 
xyi is complete", etc. # . \ 

A. 7 The security constraints provide- a rationale for the security 
necessary for the item. An example would be explaining how 
federal law requires that this data item be accessible to a . " 
certain class of user, but not Zo another. 




A. 8 It« synchronization data includes the current synchroniza- 
7 "tion status of data as wdll>£S~ strategies for maintaining 
synchronization . An example - would be a strategy of applying 
updates to an item that come ^rom different soxirces in a 
particular order as we^ 

currently at a c^rt^ih stige ini ther ^se^enQCdefiae4:^>y the . 

strategy • : ,/' ' Xs - ;,yv- .-■ 

• ; • S r 3ff * ■ " 

A. 9 "v The; integrity data includes, rules ahd^olicies for maintainin 
• r ; • data integrity^ ' •" ■ /r. '' 'y;:..^V " ! " 

— Ai^^The -r^'cav^ry-and— r^synchro 



and . when to^ back up; contains .procedures! for activating 
back-up and subsequent re synchronization and details £he 
granularity of recovery. ^ 



A.il Tite audit trail contains procedures and time triggers to 
- ^ and implies 

it& ca^^iitily '%6 trace "any transaction from its source to 
: ip&ixtput ani ivice versa. 



B.Kv' The editing and presentation formats of the dictionary '4 
system] s^ own . data will vary by user, and may be^s^gaifi- ^ 
V ■ cantly, different from each other. In addition/ i^iye^ : 
on-line control data must be properly formatted for the data 
manager, operating system,' application program or the system 

being controlled. .'.»_. , ■* -\. ^ ^ 

■. ■ * » - ■ t * ** ** ■ ■'• - ■ ■ 

B/2 The/ encryption and report generation needs are special t 
„ .: processing requirements. , E.g. ^ the DDS data must be 

transported through the network in an encrypted format. 

B. 3 The geographic location of" the DDS refers to the physical - 
•v •• location of the? -metadata; > 

; .-: . . ■ ••. ■ \ .• ■ ■■ k ■ - • ; ' - ' ■ ' ■ .: ■" ■ 

^C».l The ^security data profiles the permissible users and pro- ■ 
^cedures for dictionary items. 

C. 2 The integrity data characterizes the procedures required to 
; v , : i ^ a dictionary item* and to indicate how 
V" the procedures ate- invoked^. >' v - v 

Items A. 8 through' A. 11 are descriptions whose primary impor- 
tance pertains to the run- time administration of the data item, 
Whereas items A;l-fAv7 are of primary importance in administering- 
the use of data in database design. . A.8-A. il are considered to 
be "active" in this sense that they are on-line^, used continually, 
and potentially subject to frequent update. Descriptions in B 
and C pertain to dictionary data itself , whereas descriptions in 
A pertain to data in the environment. . : 



5 .5, 3 2 Semantic Data in the Dictionary . j ) 

The data dictionary system should contain or point to the 
semantics of ah' enterprise ' s data , including the enterprise, 
organizational, and data structure models appropriate to support- 
ing an enterprise's database applications. It should be^the sole 
source of data definitions for all systems in the environment. In 
contrast to most of the" administrative aspects of the DDS, the _ 
Semantic data is intended tb^exist in a form that can be used 
directly by data processing applications and also be meaningful 
to the user 1 Therefore , the" dictionary becomes the link to 
connect, users and applications pr*ce;sses"to 

Data seen i as characteri-stic of the semantic section of the 
data dictionary;, are outlined below: V 

A. •' Schema •.»...' ..r. 

B. Subschema (s) .. i' V . . • .. • 

C. ■' Storage.' schema' ■ ; . ••. • '.' .>:'?}' 

D. DBA schema . 

E. location in storage 

F. Entity/attribute/relationship model (or record/item/ set, 

• -•".etc.) '. . ' .';•■ ' .<- 

A. The schema is a. description of the database as viewed by its ' 
users and as processed by a. database manager (software). • 

.v--- , :v" ^•■■:-- < ■■ y:.y v " - , . " 

B. The subschemas are compatible application views of a database. 

C. The storage' schema maps database data into a format to be 

v / stored on a memory device.: . 

p. The DBA schema is the database manager 1 s own yiew of the v 
./data under its stewardship. ~ * . 

E. The location in storage provides a description of the 
distribution of data! items.. 

. V. - t; T^* enrlty/atfcribute/reiationship model documents the enter- 
prise view" of data. The view may be stated in terms of 
entities, attributes and relations, records, items and sets, 
base relations or any other appropriate group of concepts. 

X Most of these dictionary items are traditionally viewed as a 
part of a database management system; but-the group foresees a 
tighter interface between a Data Dictionary System and a DBMS. -. 
Whether a schema resides in the dictionary or in a database under— 
the control of a DBMS is an implementation strategy that is ,. ; >.jML 
immaterial to the task of the group. However, the DDS must ■ 
where the semantic information resides .In addition to 
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associate a schema with its users, applications and administra- 
tive procedure. So, regardless of implementation, the DDS and the 
database management system must be fully and functionally 
integrated. ■ 

5.5.3.3 Processing Data in the DPS 

The Data Dictionary System's description of data should 
include the /processes that can act on the data. The most signif- 
icant departure of the group from the traditional view of a DDS 
is that the DDS contains processing information. 

The processing info*rmation_ under the, ai^p 
ary system can range from the relatively mundane such as "use 
this hashing algorithm", to data semantics as represented by 
program segments (for example, "if a manager is requesting this 
data item, then summarize it and present the min, max, and average; 
but If a processing program is requesting this item, give it all 
J the stored Hata") . ^ 

* ;v: Data characteristic of the processing aspects of the^ data 
dictionary system include: 

A. ^Required inputs '-^'jiV. 

B. Requiredloutputs — 

C. Processing sequence 
?D* Alternative processes 

Ei Activation criteria for processing 

A. The required inputs are the data items which are needed for 

a process to begin. . _ - 

B. The required outputs are the data items which are produced r 
as a result of a process. 9 >: ; ■ 

C. The' processing sequence . lists the appropriate order in which 
to apply the processes. . " . . 

IK The alternative processes provide a conditionally structured 

list of applicable processing to be used in case of excepr 
?j tional events that may occur during the execution of > nfcr^ - 
mal processing sequence. \ v v * . 

E r . The activation criteria are exceptional events which acti- 
vate various processes: these ire similar to the "on 
(condition)" constructs in languages like PL/I. 

5 . 5 4 Dictionary - System Implementation ..»/•. a 

1 " - ■. V- ■ . ,*: ■.] 

The group did not directly address dictionary system '~i^l&Kr?;}<~ 
mentation issues ot^ not -> 



implementation , was important- in cons idering the role of the DDS . 
For example, the DDS processing section could explicitly contain 
programs, or simply contain references to programs that are 
stored elsewhere: either way, the programs are a functional part 
of the DDS. 

5 .5.5 Conclusion 

Group IV approached the definition of the role of ja data- 
dictionary system by "first establishing what the dictionary 
system is. The previous sections outline this groiq> f s determinar 

-tion^f— t&e-DDS-as-anr-iite^ 



the database environment. As afjch the role of the DDS is insepar- 
able from the role o£ the dataqpe manager. That role is best 
summarized as the planning, control, direction, and organization 
of the information resource. 
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6.1 INTRODUCTION 



i Database design - is accomplished in ; two distinct activities: logical 
design and physical design. In simplistic terms, logical design is accomplished 7. 
without regard to .performance, while physical design alternatives are 
' transparent to a user. Pr^maticaUy, ^ ^ twu^arent 

since they are generally reflected ih..t&e^ choice of 

bML (at least as seen >y the programmer), the considerations of a^DDS are.. 
" independent of the data model used as the DBMS basis^ > ~- 

The Physicaf Design Woridng Committee addressed ph]^^ i^es only > 
in the context otthe Data Dictionary System (DDS); Cttri^ > 
- /projected) DDS's. are incapable of ;^temia15caily organizing data for all of the , 
uses described below. Titis indicate all of . the uses of a D DS 

(e#., DDL sbura 

To> describe the us^sof the> DDS in physical des^ the : committee ; 
defined six physical datafcfcSe life cycle phases: 4 i 

■ v - v ' , ' ~t-^ ' ■ / " * ' ° V^Sv*. y<-. -; v " v 

. User Jlequireijients - response^ time, record occurrences^ > - 
frequency of use* tra^<^oij^ growth, pnvacj^ 
» : availability,^ 

. • J*ysical Design - c distribution mapping,: d^ign validation (e.g., 
simulation, analysis) protot^^ 
7>- encoding, encryption, archiving, etc. •< : \ */ ; ;" v '~' 

i Implementation * - design Confirmation,"* stress testing, data 
validation, load, etc. 

• '^Operations performance monitoring, maintaining integrity, 
v housekeeping, etc. - ' ^ V 

, • . * Evolution* - application "enrichment, revaluation, usage shifts, 
t[.-.\ \fi migration, restroeturi 

End-game - termination, shift to aistatic entity. 

*> • * '*■ ■ \ • • * ■» ■ . • *-• 

v These six phases are not mutually exclusive in time and may reoccur 

v throughout the life of a database. : ; ; v ^ ; 



y ■ 



:-*Jj*f+ m • Restart/recovery*; ] 




■■• ' •■ Physical-databaap~de^ 

stored data and ^^tabase. procedures*" The primary goal <& this process is 
■' performance efficiency within given constraints. Inputs to this process* are: * 

• Anticipated database usage 

• Available implementation techniques ? V . ,^ . 

• . Hardware and software characteristics , . . ; V- r;.v 

• * • • " .•»*•••" 

Physical characteristics of the data 

,.> • • . - TV 

• Logical data^structure* ■ • . < > 
Decisions in the design process include ^ J* 

Storage mapping 
v >. Physical record size 
. Access path^^ection 

Clustering/partitioning of data - , 

• ^ Encoding/compression/encryption of data * 
' } f • Concurrency . , 
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. Restructuring is any charge in v the logicil design of the database. 

Examples^- : . ; 

■ «k„» - * ■ %z " "■. 

A changing from a one-t'o-many to a many-to-many relationship. 

^dding^d^^ ' . ~ ' - ''>-_"' , 

Reordering data iteras^itljin a record type. :? <r 



data. 



Changing access privileges, / .* 

Reorganization is any change in the physical organizatf^of the stored 
This should be invisible to end-users or application progra«uners,. excepts 
via performance. Examples: ^ i < 

; • Changing from hashing to indexing. ' 

• Eliminati^ overflows in.#n ISAM file. . ~ • * 

v * Changingiti^Ween data compression and non-compression. ^ 

-Note that a^Wahge due to logical design* will usually result in physical 
r chai^W while pfiysical : changes -m 

'*•-■■ ■ 4 ' 

" . - * : * 

..r ■ * r ■* ' . , 

. •» . '• ' : • 1 ' 1 ' ■ • ' " ' • .'. ' * " 

6.2 '". REQUIREMENTS - METADATA REQUIRED^IN DDS". .- 1 . 

ifj The DD#£for a new database, is initially »created\5^rig /the 

^requirements definition- phase using the logical design componentsgEntities,. . 
Elements,, arid Relationships) as its basic, input data. During the life/cycle of 
the database, data about the logical- elements and their physical counterparts .„.., 
win be systematically captured and organized .within the DDS. Durin$_thte>;\ ? £ 
initial phase, ^ata is collected from external sources (i.e., not from database - 
• operations). ' Such se»rces- include. *. user design specifications, desjpi?. 
assumptions, statistical inferences from existuig systems/files, etc. . ..J».* 



Djuring this phase of design, the .enigjpsis is oh how data win be used, t 
much data exist (or will exist), performance requirements, and operational 
environment. Vlt is important to note that the data about data lyhiph *re to be 
coUected are the same as those requested in the non-DDS eny^nment. The 
distinction involves recognition of the need to systematlcaliy/oi^anize the 
data in both humfcn and machine readable form* -.y": 



'Ik 1 " 



c ... .->. ■ • 



- * During the generation of the lexical design (an input to physical 
design), metadata is captured about the four basic database components 
entities, elements, .relationships and subschemas (user perceived virtual 
recordsX The DDS must be capable of representing ^ <tetia about these 
components in human and machine useable format The metagpta needed ar^: 



Logical Data Entity 



Occurrence volume , ty 

Growth rate addition^ Frequency/Qycde ... ^. 
Growth ratejdeletion: Frequency/^iljB^^ 
Size^total of; element sizes - can begenerated) 
Ace$s^privil^es (e$& f read, add, delete) * 

Priv^#^la^^^^r# ^ 

Srements (e«g., within J»o hours) ? 
^ifequirements (e.g., f asteist^esponse required) 
^(e^g v how long to keep) business and external 

Element (Attribute) 




r 



^jC^^-r . 

>>■ >^ : ; 

■<jrvj^ze-v. r - 1 ■ • < . _ , . ■/' 

sa^v* 7 I^Scfrmatfe) by frequency (may relate to operation) > : 

/ ,^^^Mityfe) describ^t^element _ . 4 _ . 

Integrity rules (e.j£, val^e^SOO-SOtfb) ,,v- r ; 

" Privacy requirements (r^ted to ilers) . . 
v Number of ^ifcstinct values (size of domain) and growth rate (e.g., 

imy ^ \ < ,,' '* 

- Modification and selection operations) : . 

Access privileges (e.g., read; modify) V •, > v , 

Description of identifying characteristic of element c " "78 

' (e.g.,, identifier/non-identifier) 
Availability r^quirement^(constraining requirement). 
(^nsi|raint (business and external) 



Logical Data Relationship 
■Owner : 

MembeKs) * 
.Average size of set/member type v 
Maximum size of set/member type * 
Minimum size of set/membe^^e 
Median. size of set/member t3|Msp \ 
Frequgpcy cjistribiftion type/cotlnt" 
: Growth rate/member typfe . - 
v ; Addition of new entities > 
Deletion^ entities ^ 
Modif icaron of set occurrence membership 
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Logical Operation Against Virtual Record 

Type (e.g., access, addition, deletion, modification): 
"... >f M) non-key, 2) key, ^ relationship key 
Frequency per cycle 

Processing mode (e.g., batch or interactive) 



is 



Response constraint (e.g., time) with priority— may vary wi*h user 
Sub-schema: entity and elements (attributes) 

Access type feg.rsequen.tjal; serial; random; relationship^) — £ : 
with sequence — with elements* for sequence, no prime-*e||jf 

elements) ' : 

Purpose (e.g., to pt^g#e standard cost; to generate bank 

Number of virtual records expected in response 

v ■ ■ t*7 „. 

Notes: 1) All terms are used generically ' : V?V"V^ 

~ 2) Only factors which may be needed for ^physical - 

database design included ',' .jjji 
' 3) Some factdrsa«fll-not affect physical datpase design 

- with all DBMSS ". / ; , • . \. ' v- - 

. ' 4 4) " Not all factors are developed to the same~ level of .: .. 

. detail (e.g., privacy is not detailed, logical operation 

needs more development and checkingiOf ideas)^. ^ ~ 



6.3 PHYSICAL DATABASE DESIGN PHASE 



There areiSumerous decisions and actions required; to arrive at 
.physical database design which will efficiently support a logical database 
design. The basic objective of physical database design is physical grouping -™*9r, 
and placement of data which -efficiently supports specified and projected dfi^ v. 
^storage and retrieval while observing established requirements and v- , 
constraints. It should be noted that there a^e-usually several possible physical , 
database designs which can satisfy the,sam/logical database design. 



Three major subphases of the ptec%database design process are 
identified below. The development sutohase-||§Bs with the decisions and 
actions leading to a specific design. The aUoSmn subphase addresses the 
distribution and placement of records within the available stora^^space. The 
validation subphase is concerned with specifying or" aSC^mplisiang procedures 
leading toward validation of the physical . database; Le^oes the design satisfy 
the requirements and. observe the constraints. * ' ■ ■ 
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Design Development - v " : ... ... -x^"-'. : , v 

* 6.3.1.1^ Distributed vs. Non-distributed. Affects design at highest level 
since, in a distributed system, all the~physical aspects of a database are 
Represented at each node of the network* Data needed for distributed design 
Incl ude the same data as_ needed for non-distributed da tabase de ^gn and, in 
addition, include external requirements for data distribution: ^ 

• number *>f podes in the network 

' . data description at each node 

S " \ size of database (record . occurrences) at each node 

frequency data regarding the source and object of processing £ 



6.3.1.2 Concurrency^ This addresses^^e^s^ 
accessing data simultaneously. These issues -arise* &u^ 

bef ween users wKoS^ attempting to^update or modify ■tte ; s^^fl?(!^^^^«^^^ 
physical database 1i€£ign ^Jeye}, the concurrency issue may \ 
partitioning and daia^d^^^r^p avoid contextual conflict, t Metadata -.^S^A'^.i^^ 
to support analysis and decision making here are: - ^r^^^^^^ 
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usee versus data usage • 

• \. * mode of use (update vs. retrieval only) # 

• v frequerfcy of use 

6.3. 1?3 Storage/Access Methods. This aretftieals with the section of basic 
methods for organizing, storing- and retrieving of. data. .Da^ organizations 
include sequential, direct, indexed and linked. Many variations of these 
techniques exist and are in common usage. The type of data nei^Sfl^to support 
decisions in selecting storage/access methods include: 

6.3. 1.3.1 Storage frequency and type. r 

• * insert/update 

• t sequencing requirements (e.g., by key value, within set) 

6.3.1.3.2 Retrieval frequency and type. ' . 

retrieval of records in a specified sequence 

• retrieval o&allo^ part of a set r * v > 
boolean operations 

S- 
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6.3.1.4 Selected Design Limits, This area%deals with the establishment of 
,, telf-imposecP design limits^such as maximum nuihbers of record instances, a 
stipulate maxima c^lKgi^tj^binter^sizes, maximum- 
field sizes, key sizes, etc* for this area would 

'taij^t^tabare 



frequency and numbers of transactions or accesses ,by reciprds^^ 
data classes , v 

estimated .flumber of unique key values _ : 

the ratio of database entities to defined relationships 



\ ■ • estimated storage requirements by database record type or data 

ClaSS • -. V.;-..' 1 -'i-. • ^ ' 

6.3.1.5 Hardware/Software Constraints; ThereTnay be numerous constraints 
imposed toTeform the design of a physical database T>y the computer hardware 
and supporting system level software. The most obvious hardware constraints 
include Direct Access Storage Device (DASD) type and number, as well as 
numbers of channels. These constraints serve. to,bound the extent to which 
data allocation can be accomplished across different DASD for efficiency of 
access purposes. The most significant software constraints are those related t 
to the DBMS used to implement the design/ Examples of software constraints 
that can -impact physical database design include ,page or block size range, 
maximum numbers of record occurrences in a file or data class, maximum 
numbers or record types, maximum number of relationships between record M 
- types of data classes.' The types of metadata needed would include: 



types 

• catalog of hardware constraints 
. catalog of software .constraints , t . 



6.3.1 .6 Expansion Factors. ., This area addresses the problem of arriving at a 
/physical database design whose realization is capable of gracefully expanding 
^^ommodate.more data of the same or a different type. This impacts the 
'decisions on ffl£ loading, paititioni^ r .«lustering, and access methods. Data 
*" ifSeded to support d^sibns on expansion/actors include: . ~ - 

' identification Of data types, data occurrences and data rnapping^ 

'r:^^^. -S^* whicli j^^je^ toexj^insft» 

'**~f,/ fe^v the.^^^^^gnitude of expansion of each of these items 



• 7 ; \ Phys^^ Record Size; are^T addressed 

^determining the size of the physical record wtfcl^ Vy'. 
unit of storage and retrieval to/from secondary^to^fe m edia. Un^ttions 
may be imposed by the database system ot^S^s^ondary storage. Large 
physical records (blocks) * may restrict the number concurrently available in 
main storage while reducing the need to transfer blocks* _The physical record 
^size-desigrMtecisicffl^ 



^ „ .^^^ probabili^^^^cessing more than one record in a block 

. ;.• . block loading density - 

* • efficiency of the secondary storage system . * . 

£.3. 1.8 Partitioning . Segmenting a record- tyjie into two or more subrecord 
types is record partitioning. Partitioning a file of records into Iwol or more 
subfiles is file partitioning. Record and file partitioning may occur for 
performance or privacy/security reasons. Input to a partition decision process 
m may include: ■ " ; 

Attr^ute and subfile reference f recencies .-" 

• Attribute length and subfile sites 

.■ • Attribute and subfile privacy /security constraints 
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fc'3.1.9 Clustering . Intra file clustering involves the selection of a key on ; v;:- 
which records of a file are to be sequenced. Interfile clustering involves 
placing records of one file (e^j., member records) physically close or adjacent £ ; 
to records of another file (e;g., owner records). < Input to the clustering 
decision process is: . • 4. • ft 

• Operations on single^ files and *he frequencies of the^B^fe^ 
operations; operations on^interfile linkages and the frequencieig^^r: 
of these operations; a ~^ 1^ :- ^^^^ 

^ ■ List of keys that are candidates for intra file clustering. 

6.3.1.10 Mapping ^: > ' ^ 

6.3.1.10.1 Definition of Mappinp; ^ J A- specif icatipn of how objects and 
operations at one level of abstraction correspond to objects arid operations at 
another level of abstraction. Examples of levels are: user level (external : 
schema), logical level (conceptual schema), and physical level (internal 
schema). Examples of objects are entities, relationships, attributes, pages, / 
and pointers. Examples of operations are "find owner" and "follow pointer.* > 

Top-down .database design involves, designing logical objects and then 
mapping them into physical objects based fipon performance criteria, etc. The ' 
DDS should documentCthe miqpp^g- * r "' 

•#' : , - . 



6.3^1.10.2 Definition of Physical Data Independence; - The ability to 
change the physical database design while preserving the original logi- 
cal-database design by changing the logical-physical mapping. / ^ 

6.3.1.11- Recovery and Restart. This area concerns the physical database 
design issues relative to insuring that tbe database, either in whole or 
in part, can be recovered and restarted within the required time frame. 
Pbysical^database level design— activities that can be-infiuenced^hy-^ 
recovery/restart 'considerations include data partitioning and planned 
data redundancy. Recovery and restart requirements are established for 
data classes with respect to users. The basic question to be .answered . 
is, "How long can a user afford to.be without data support?" The. answer 
establishes the maximum time frame within which recovery and restart 
must be accomplished. Metadata needed to, support physical design deci- 
sions related to recovery and restart include: r 

- • **: • •• •.'-;*•' ... ■ • : . 

maximum time: that a data class can be unavailable" ; 

.-7". " . 

.. identification of data classes that constitute minimum working^ 
sets of data classes, siich'.that all" data classes of the set must— ^ ; 
be available for effective processing to take place 



6.3.2 Physical Allocation 

6.3.2.1 Sjjace Constraint. Information on the available storage space is 
necessary to support decisions on the allocation and distribution of the 
data class occurrences across the available DASD. This information is 
constantly changing as the available. DASD capacity changes due tc- allo- 
cation and deallocation actions. Meta^a- "needed here include: .£» - 

. number, of data classes (sets) that can be defined foe each DASI> 
unit • 

. ayailable space for data storage for: each DASD unit 

7 v . • - , 

6-3.2.2 ffpace Allocation. This involves the assignment of files to 
storage me'dia and tl*e allocation of storage space for these file*? A 
goal of space Allocation is to achieve an efficient and balanced^ utili- 
zation of available storage devices* Input to the space allocation pro- 
cess may include: " - 

w * . "■ T ... •■ ;■- 
. ; size of each file 

*»-.•■»• * 

■„>'..'* . * 

growt^ rate of each file ■ 
' 4* . access frequencies of each file 



storage capacity of each device 




■ *T*^- V.- ■.'-.» 
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6.3»3 Predictive Validation* : [ .^ 

Analytic models, simulation models, and prototype databases are tools that are 
used as design aids. Each has its strengths and weaknesses Predictive 
validation involves the use of these tools to confirm that the specific design 
constraints have been satisfied. . r 

J»»3.3»l Analytic^, Models. Analytic models are efficient design tools. 

circumstances, be evaluated efficiently. Analytic models have been developed 
to simplify decisions concerning partitioning, clustering, -physical record size,, 
and concurrency^ among others. The greatest limitation of analytic models is 
that many problems are too complex to be addressed using analytic 
techniques. In such cases, simulation and prototyping may be used. Input to 
analytic models may include: : . V 



• Logical ^data a*juc ture and its descriptive characteristics fe.g.> 
number of es^i^s of a particular type) . , ^ 

• * Transactions that are to be processed and transaction frequency 

/ ..... Simulation is a powerful tool for validating physicaldesigns. It can be 
used to: access global feasibility (i.e., will the implemented design meet the 
processing and storage requirements). Typically, simulation is uSeo to -predict 
$he behavior v of* complex : Systems. Simulation experiments a^Haesigned to 
demonstrate the performance of database systems under various conditions of 
-prqpessirig load, logical and physical* data organizations and database size. 
Data needed to support the simulation of a physical design include: 

*'1 m • ^ihe logical data structure • 

•• •' ■■■ ■ . : ■ 

• ' ... 1 the physical data organization 

• transactions to be processed * 
^ ^ • the DBMS software 

• placement of data on secondary storage 




6.3.3.2 - Prototype Approach. This area. ' deals . wtth the design and 
specification of a prototype^ based method, for validating that a^Jphysical 
database design satisfies the? established requirements and observes the 
stipulated constraints. A prototype based validation process, is one that 
includes database load,, database maintenance . and database use (basically 
applications software)^sbftware a[s well as a representative database. The 
objective of the use of * the software with respect to the prototype database is 
to demonstrate that all required data types and relationships are created and 
useable for generating the needed information. % 



^^The prototype database do6s hot have to be equivalent to the ex- 
pected live data with respect to quantity, or volume of data. It does 
have to be logically equivalent to the live database. This means that 
each unique data value and combination of logical conditions should be 
represented. The metadata needed to support this area include: 

. ■ logical data. structures^ defining logical entities and relation- 
ships -■■ * 

. . entity keys used for identiAcationv^eference and' cross refer-* 

ence' ~ • T - 9 

• response requirements by data class and operation-- 



'report requirements m ■ 



. transacti9ns tha:t must be processable 
. access control, privacy, and security requirements 
6*4 IMPLEMENTATION ^ ■ ^ ' 

Chis is the phase where the user loads the database that has been 
Lly and physically designed — in other, words, the "moment of 
truth." . * u 

6.4.1 Conversion Plan ■ 
Whether converting from manual records, standard files, or another DBMS, 7 
it is essential to have worked out a conversion plan for the data in ad- 
vance (see Data 'Base Directions ; The Conversion Problem , NBS^ Special 
Publication 500-64.) - T ^ 

6.4.2 Data Dictionary System Assistance . 
Whether an active or passive DDS is in use, the DDS should reflect in- 
foqwfeion about the new database design, arid possibly, the' older design. " 
TiigHV'now, the DDS can provide a road map for .implementation. In the 
future, as Ronald -G. Ross asks in Data Dictionaries and Data 
Administration ; Concepts and Practices for Data Resource Management 
r/iMflrnM T 1Q81 * excerpts printed in Computerworld , Vol. XIV, No. 38, Sep- 
tember 17, 1980, ppw^^-47), why shouldn^ it be "possible to use an ac- 
tive DDS system direc?&y for assistance in the automatic installation- of 
the database. 

6.4.3 Prototyping - > . 

Just as the physical design of the database can be tested and ■■; modified, 
during the design phase, so can the initial implementation itself be a 
prototype. There are many examples of -interactive decision support sys-. 
terns ' and . "user friendly" database management systems, usually for 
smalifr-scale databases, where efficient performance is hot as important 
a consideration as fast implementation. -In these instances, the proto- 
type may turn out* to»be a satisfactory final solution. 
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.^*^5lt^^c^^^^i^data structxire^ncs/eases or the sheer physical size of a 
^ very large *da^^| leads to-a-<K>mpl^^ more 
> than r prptotyp^jB necessary. For re^anipl^ a: test database, representing a 
partial, loacf ojsBte* database,, , might be A established v and tested before a 
- complete databwvjs loaded." ' * " " , :7 : - ' 




jOuS- V^^tidnjof^the Design ' \ - , ■ ' ■ /; : , Y 



Satisfactory performance of a prototype, a test database or a complete 
database in |l production system en yiromnent is necessary to, validate the J 
physical design of the database. Despite the claims of vendors, the hopes of . 
in-house technicians and the results of today's analytical or simulation models, 
it is not until final implementation that users know they have^succeeded. 
Unfortunately, except for quickly installed prototypes, it is usual^very costly 
and time-consuming to get to the implementation phase. It can be disastrous 
to get this far only to find that one must go through a major redesign io obtain 
adequate response times 'or avoid installing 20 additional disk drives beyond 
the 10 estimated! Often, by this time there are waiting application 
de velopment teams and' users who will be extremely unhappy at further delay. 

6.4.6 Data Validation x ... 

-the process of loading a database may turn up significant discrepancies from 
information gathered during the Requirements phase. It can be most 
embarrassing to discover at the last minute that there are, in fact, twice as 
many vendors as^ planned or duplicate names or codes tor simply^thatr-the old 
data is "dirtH^ or full of obsolete codes. Again, good systems anaysis work 
during the Requirement phase and Physical Design phase -can help minimize; 
discrepancies. . Additionally, in today's data processing environments, users 
may find it worthwhile to make statistical or editing runs against the data 
prior to conversion (or even prior to Physical Design), using tools such as 
general purpose file management utilities. Since some of today's DDS's 
already provide for limited statistics and data item editing criteria, it would 
seem possible in the future to -establish and use such infonnation in a better 
organized, more automatic way with the DDSs during the Requirements and- 
Physical Design phases;. Also, if the f uture state of the art someday allows us 
to achieve automatic^kSadiggf i>f the database using the DDS, we might 
reasonably expect n editing^i&current with loading. 11 " >- 

6.4.7 Stress Testing <iS?!$% /:" ■ ■ * 

When a new database has begaicfede^but b^fpre it has been fully turned over 
to operations, it may be advisab^ ; j^^onduct a stress test— : especially where ., 
on-line response times , are ^itical or for a complex or very large database. 
For this, the desigher/impfementor should pre-plan with end-users and 
operations a high volume tesf of transactions or 'concurrent terminals 1 access 
.of /the database* The idea is to flush Wt inherent performance problems and / 
take corrective action before going Tive. 11 
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6.4.E Confirmation 
wmie the date and physical ^ 

final confirmation of successful de§^^ until , 

the database has bee^^o for am 

appropriate length of time.»^ sliould^be pre-established • 

with users 1 and 6pera:tibns* prior €^reera 

phase, the monitoring activity will: ^ve sometMng to compare against 
Establ^^e^measUrc^ to avoid the problem of a "moying 

target" as u&ers become more famiUar with performance characteristics and * 
capabilities. In the future, it wbuld be desirable to have .a new generation DPS' : 
with the capability <of carrying Both expected - performance measures > and 
monitored performance results, so that exception reports could be directed to 
t^e DBA for investigation and corrective action! -,-.s . 

> ' - ' • ; . • ■ ■•" ' ".'•*•;' ,j-:'^r •; • ; - •■ 

6.5 OPERATIONS ^ 

This phase of the database lif ecyclg is y the period of operational use in 
meeting the needs of the enterprise. If the databases ^^essful, tins will be 
by far the longest phase. During this phase the physical characteristics of the 
database and the way it is used (i.e., the user's view of virtual records) will 
continuously and gradually change. This implies the need to continuously 
monitor perf orftrance and its physical attributes, to systematicsdly collect and 
Organize Jhese data, and to selectively adjust the physical database design. 
Note - tha&such changes in physical characteristics are hot uniform across 
either logical or physical subsets of the database; The panel recognized the 
DDS as the logical mechanism f or orgkhizii^. these measurements of .physical 
attributes. * ; - * .-v ' -r - % 7- ''^i-'^ z r 

6.5.1 Cath^ng.Perfy mance Data ' 

• " Who invokes the gathering? (DBA, automatic) 

When invoke the gatheriifc? ^ * ^ 

• WlUt gather, and how? \,' 

- --T- ■ Compare actual characteristics #f_ data and usage with Phase I 
estimates. - " ^ • : . . 

• Graripilarity of measurement. k 

^ What is overhead of gathering? • ; / - ^ " 5 

6.5.2 Aggregating Performance Data 

How? - ■ t- '• r- •' 

i. '• .•» , ■.*•.. 

Time granularity. , 
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„ v 6.5.3 Repbrtiii^^Performanee Data 1 " 

• » *Wbo invok^the reporting? (DBA, automatic) , 

' ■'•->■* .■ < ' ... ; - :'• ./ . .- • ■ •: 

• How often report? JH : : 

p • How present? (machine-readable and human-readable) 

^Who has access to data? t - 

- 6.5.4 Analyzing Performance Data ^ * ^ f 

What Measures of performance? v 
■ • . Compare with desired/predicted performance* 

Database performance vs. whole system performance. * 

• How determine what caused a given aspect of performance? 

6.5.5 Performing Maintenance y"- * / * 

•'" ■ , Who invokes the maintenance? . (DBA, automatic) 

• Invoke under what eircumstances? (periodic (e*g., ISAM), upon 
demand (e.g., VSAM) ) ^ / : 

• . How perform? (incremental (e*g., VSAM), offline unloeid^reload 
' or copy (e.g., ISAM),x|&ine in-place (e.g., an^IDMS^ utility), 
. concurrently with q^j^^esearch topic) ) 

- > , • . ;> . ■ - ; «&r 

^- X Note: ^Most 6^ " this' applies also to one-sfiot reorganization 
(definitional changes, in evolution, phase). V 'i * 

6.5.6 DPS Usage. V ' : " ^ 
The DDS is the vehicle for documenting th^ answers to some of these 
questions . . -! ^ 

Document: Desired performance from Phase I 

" - Predicted performance from o Phase n 

' Actual performance from this phase * 

; Estimated characteristics of data and usage from Phase 1 

\ . Actual characteristics of data aftd usage from this phase/ v 

:: ' 6;6 ' EVOLUTION- 

Virtually any requirement in Phase I can change. This may Require * 
. lopcaf&reaesign . (restructuring) or it may require just physical redesign 
r: (reorganization)? . - 
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Poor performance may- reauire ptejKal redesigru We tha^whtinue 
through the cycle w of re^plemerftation (perhaps) and hew operation* This 
discussion focuses upon physical/re-design. 7- c 

• Different types of evolution, in different ' circumstances, have , 
different degrees of difficulty. Physical data independence eases the problems/ 
of reorganization, since users and applications a^e unaffected (except via 
perf ormaace changes). Without physi cal data independence, reorganization to 
Improve performance can affect apphcation^tfii^Teq^ 
modification. This * modification can range from recompilation to 
reprogramming. - : - ^ 

As ah example* of evolution, suppose that in an energy: shortage, a 
company decides that it must access personnel records by home zip code for 
the purpose of forming car pools. To accomplish this eff iciently r the DBA 
decides to create a new secondary index. Depending upon the DBMS, the 
difficulty of doing this ranges from (1) adding a new table to (2) recompiling 
existing tables and re-loading the database. 

another example, adding a new application or changing the 
frequency of execution of an existing application may* result in -a new 
performance bottleneck, wjpch then requires reorganization. 

6.6.1 Definition of Two Types of Reorganization 

6.6.1.1 One Shot Reorganization. Change definition of data? not performed 
repeatedly (at least not for a database whose characteristics are stable). 
Examples: Change from indexing to hashing; move to a new device. 

^Maintenance. Change just occurrences, not definitions. Performed- 
y (periodically or upon demand). Examples: eliminate overflow in 
VSAM split; compact ;to recover space. 

6.7 END GAME « • 

."■■**V>" ****.* ^ ' ■ • • 

At some point in the life of a database* operations win eventually be 
shifted (partially or in total) to a distinctly different mechanism (a file or 
another^database). This is a conversion similar to the originating co^wrsion 
and as sifeh it is necessary to establish correspondence between the old and the 
new data forms. ^ - 

An analogous cdh version prqcess^wiu normally be initiated at the 
outset of , the operational* phase; specif ically, data archival. The (dfistmctibn 
between these two types of conversion is subtle - totality Versus selectivity. 
In those rare instances when data is rfo longer captured the end-game archiving 
of data is, in fact, a total conversion. ^ v/ 
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v Items for consideration r^tive^to the termination of a system: • ^ 

. /Graceful exit ' • " " : ■ - ' 

. • ' ^^^eterition' of Records (intem^^ external). _ . /)r ; / J 

. ^->ij^Retention of record format 
~ . • ^ ftcces^bffi^:of"re^rtST^ - ~ 7 r— ~~ ~ • ... . a 

Retention of access programs • , 

••• : 1 ^ . .-. • '/•; 

: • , Jigpact on other systems 

v Changes to structure to support "new 1 ? retrieval frequencies 
Entities/Attributes related t6 the demise of a system: 



• V Users v : < • ^ : \ *. . ■ 

Retention time for data . ; 

• ^ System requirements (operating system, DBMS,: etc.) 

Programs to access date y - 

•■; Data v • - 

Data aggregates (Groups)' ^ r 

Structure - * • • . r . ' 
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.7. ^PftRT ICI PANTS 



* ^ "fe ' - Ttfe/ fpI3^ing" is a. ' 1 i s t- of - panel ' 
' ^iforkslioB par tadlpan ts . i '•" *\7 » 
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Prof. Joseph Browrismath 
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